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ABSTRACT 


The  objective  of  this  study  was  to  determine  a  methodology  for  implementing 
feedback  loops  into  a  logical,  automated,  computer  assisted  probability  assessment  tool. 
A  tool  exists  called  the  GO  program,  which  allows  for  systems  to  be  modeled  in  a  block 
diagram  or  schematic  format  and  then  analyzed  in  a  structured  manner  to  determine  the 
probabilities  of  outcome  events.  The  challenge  was  to  incorporate  a  method  for 
analyzing  feedback  loops.  Given  the  difficulty  involved  with  using  computer  code  to 
analyze  feedback  loops,  reliability  engineers  would  normally  create  two  separate  models. 
To  allow  for  a  single  model  to  be  used  and  achieve  consistent  and  repeatable  results,  a 
methodology  for  creating  multiple  layers  of  feedback  loops  in  increasing  complexity  has 
been  analyzed  for  use  with  the  GO  program.  Monte  Carlo  simulations  for  each  of  these 
representative  models  have  been  constructed  and  analyzed  to  validate  the  adequacy  of  the 
GO  program  to  effectively  create  probabilities  of  event  success  and  failure.  With  the 
demonstrated  ability  of  the  GO  program  to  correctly  model  feedback  loops,  it  clears  a 
path  for  the  Department  of  Defense  to  investigate  the  benefits  of  adopting  a  standardized 
approach  for  the  analyses  of  complex  systems. 
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EXECUTIVE  SUMMARY 


The  purpose  of  this  study  was  to  determine  a  methodology  for  implementing 
feedback  loops  into  a  logical,  automated,  computer  assisted  probability  assessment  tool. 
The  GO  program  allows  for  systems  to  be  modeled  in  a  block  diagram  or  schematic 
format  and  then  analyzed  in  a  structured  manner  to  determine  the  probabilities  of 
outcome  events.  The  challenge  was  incorporating  a  method  for  analyzing  feedback 
loops.  Feedback  loops  are  difficult  to  analyze  with  computer  code  because  feedback 
loops  often  have  elements  in  the  loop  that  are  not  independent  events.  Dependent  events, 
when  encountered,  need  to  be  accounted  for  in  advance  when  they  are  incorporated 
within  a  block  or  schematic  diagram.  When  processing  data,  computer  code  cannot 
logically  process  a  failure,  which  represents  the  feedback,  and  a  return  to  the  beginning 
sequence  to  try  a  different  path,  which  represents  the  loop.  Given  the  difficulty  involved 
with  using  computer  code  to  analyze  feedback  loops,  reliability  engineers  would 
normally  create  two  separate  models.  One  model  would  be  used  to  determine  the  system 
probability  and  another  model  to  estimate  the  feedback  loops.  These  models  would  then 
be  combined  in  the  best  manner  possible  given  the  background  and  experience  of  the 
engineer. 

To  allow  for  a  single  model  to  be  used  and  achieve  consistent  and  repeatable 
results,  a  methodology  for  creating  multiple  layers  of  feedback  loops  in  increasing 
complexity  has  been  analyzed  for  use  with  the  GO  program.  Monte  Carlo  simulations  for 
each  of  these  representative  models  have  been  constructed  and  analyzed  to  validate  the 
adequacy  and  accuracy  of  the  GO  program  to  effectively  create  probabilities  of  event 
success  and  failure  when  dependent  feedback  loop  are  considered  as  part  of  a  single 
modeling  effort  and  analysis  of  a  system. 
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I.  INTRODUCTION 


A,  BACKGROUND 

GO,  an  event  sequenee  analysis  tool,  has  applieations  in  the  diseiplines  of 
reliability,  availability,  safety  and  risk  assessment.  The  GO  Program  was  first  developed 
in  FORTRAN  program  eode  and  ran  on  VAX  IBM  maehines,  it  was  later  further  updated 
to  operate  on  personal  eomputers.  The  GO  program  was  initially  developed  by  Kaman 
Seienees  Corporation  with  funding  provided  by  the  US  Army  in  1967.  Input  to  the  GO 
Program  is  a  funetional  and  logieal  model  ealled  the  GO  Model.  This  model  is  a  textual 
deseription  of  an  event  sequenee  diagram.  Event  sequenee  diagrams  are  eonstrueted 
using  different  types  of  modeling  elements.  These  modeling  elements  represent  the 
funetions  of  eomponents  and  assemblies,  ineluding  simple  and  eomplex  eomponents, 
logieal  OR  and  AND  gates,  eontaets,  signal  generators,  ete.  These  modeling  elements 
also  inelude  probabilities  of  oeeurrenee  via  the  systematie  proeessing  of  the  modeled 
system  by  the  GO  Program.  The  GO  Program  evaluates  eaeh  of  the  user-defined  and 
user-assigned  signal  states  of  eaeh  of  the  modeled  elements  and  will  produee  tables 
displaying  the  frequeney  or  probability  of  eaeh  modeled  element  to  be  in  the  defined 
signal  state.  GO  software  is  used  to  reduee  any  diagnostie  problem  to  a  deterministie 
solution,  when  the  eause  of  a  system  malfunetion  is  inferred  from  sensor  information. 
GO  analysis  teehniques  are  used  to  identify  the  eause,  or  potential  eauses,  of  system 
events  or  failures.  System  safety  and  reliability  engineers  are  the  typieal  users  of  this 
type  of  information  and  would  most  direetly  benefit  from  the  data  generated  from  GO 
analyses.  As  sueh,  the  input  data  would  be  developed  and  provided  by  safety  and 
reliability  engineers. 

B,  PURPOSE 

The  purpose  of  this  study  was  to  determine  a  methodology  for  implementing 
feedbaek  loops  into  a  logieal,  automated,  eomputer  assisted  probability  assessment  tool. 
The  GO  program  allows  for  systems  to  be  modeled  in  a  bloek  diagram  or  sehematie 
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format  and  then  analyzed  in  a  structured  manner  to  determine  the  probabilities  of 
outcome  events.  The  challenge  was  incorporating  a  method  for  analyzing  feedback 
loops.  Feedback  loops  are  difficult  to  analyze  with  computer  code  as  feedback  loops  will 
often  have  elements  in  the  loop  which  are  not  independent  events.  These  dependent 
events,  when  encountered,  need  to  be  accounted  for  in  advance  when  they  are 
incorporated  within  a  block  or  schematic  diagram.  When  processing  data,  computer  code 
cannot  logically  process  a  failure,  which  represents  the  feedback,  and  a  return  to  the 
beginning  sequence  to  try  a  different  path,  which  represents  the  loop.  Given  the 
difficulty  involved  with  using  computer  code  to  analyze  feedback  loops,  reliability 
engineers  would  normally  create  two  separate  models.  One  model  would  be  used  to 
determine  the  system  probability  and  another  model  to  estimate  the  feedback  loops. 
These  models  would  then  be  combined  in  the  best  manner  possible  given  the  background 
and  experience  of  the  engineer. 

To  allow  for  a  single  model  to  be  used  and  achieve  consistent  and  repeatable 
results,  a  methodology  for  creating  multiple  layers  of  feedback  loops  in  increasing 
complexity  has  been  created  for  use  with  the  GO  program.  Monte  Carlo  simulations  for 
each  of  these  representative  models  have  been  constructed  and  analyzed  to  validate  the 
adequacy  and  accuracy  of  the  GO  program  to  effectively  create  probabilities  of  event 
success  and  failure  when  dependent  feedback  loop  are  considered  as  part  of  a  single 
modeling  effort  and  analysis  of  a  system. 

C.  RESEARCH  QUESTIONS 

Can  the  GO  program  be  revised  to  allow  concurrent  performance  of  safety  and 
reliability  assessments  on  dynamic  systems  which  include  output  feedback  control 
functions?  To  be  able  to  answer  this  question,  a  foundation  of  the  operation  of  the  GO 
program  had  to  be  established;  starting  first  with  a  simple  and  straightforward  example  of 
how  the  GO  computer  code  processes  data  and  arrives  at  a  probability  of  success  and 
failure.  This  example  would  be  supported  by  an  accepted  method  of  calculating  the  same 
probability  of  success  and  failure  manually.  After  this  initial  step,  a  feedback  loop 
example  with  a  single  feedback  element  would  then  be  introduced.  To  further  validate 
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the  GO  analyses,  a  Monte  Carlo  simulation  would  be  designed  to  independently  verify 
the  results  of  the  analyses.  Next,  a  feedback  loop  example  with  two  feedback  elements 
and  another  with  three  feedback  loops  would  be  processed  by  GO  and  verified  by  Monte 
Carlo  simulations.  These  investigations  into  increasingly  complex  model  would 
determine  the  adequacy  of  the  methodology  used  for  designing  and  implementing 
feedback  loops  for  concurrent  performance  of  safety  and  reliability  assessments  on 
dynamic  systems. 

D,  BENEFITS  OF  STUDY 

There  are  multiple  benefits  to  be  derived  from  performing  this  study  and  verifying 
the  results.  Listed  below  are  ten  specific  benefits  from  using  the  GO  program  and  the 
methodology  described  in  this  paper  to  implement  feedback  loops  to  allow  for  concurrent 
performance  of  safety  and  reliability  assessments  on  dynamic  systems. 

1 .  There  are  no  commonly  known  commercial  reliability  modeling  tools  available 
that  are  driven  by  a  functional  model.  Performing  reliability  modeling  using 
mathematical  models  introduces  errors  when  function-level  probabilities  of 
occurrence  are  involved. 

2.  There  are  no  commonly  known  commercial  FMECA  (Failure  Modes  and 
Effects  Criticality  Analysis)  tools  available  that  are  driven  by  a  functional  model. 
Performing  EMECA  manually  using  worksheets  is  likely  to  introduce  errors  when 
complex  systems  are  involved. 

3.  There  are  no  commonly  known  commercial  event  tree  analysis  tools  available 
that  are  driven  by  a  functional  model.  Performing  event  tree  analysis  manually 
using  worksheets  introduces  errors  when  latent  operating  modes  are  involved. 

4.  There  are  no  commonly  known  commercial  fault  tree  analysis  tools  available 
that  are  driven  by  a  functional  model.  Performing  fault  tree  analysis  manually 
using  logic  symbols  introduce  errors  when  complex  systems  are  involved. 

5.  There  are  no  commonly  known  commercial  engineering  tools  available  that 
integrate  reliability  modeling,  EMECA,  event  sequence  analysis,  and  fault  tree 
analysis.  Performing  these  analyses  separately  using  different  methods  is  labor- 
intensive  and  introduces  errors  when  trying  to  integrate  the  results. 

6.  There  is  no  commonly  known  commercial  suite  of  integrated  safety/reliability 
tools  available.  One  of  the  benefits  in  a  future  study  is  the  research  involved  in 
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defining  an  "enhanced  GO"  tool  which  allows  integrating  safety  and  reliability 
analyses  via  output  which  includes  function-level  failure  cut-sets  and  function- 
level  probabilities  of  success. 

7.  There  are  no  commonly  known  commercial  reliability  modeling  tools  available 
that  are  driven  by  a  functional  model  which  is  compliant  with  an  industry 
approved  standard.  The  AIAA  S-102  Mission  Assurance  Standards  Working 
Group  is  interested  in  coordinating  the  further  development  of  an  "enhanced  GO" 
to  create  an  Open  Source  tool  which  is  driven  by  a  functional  model  that  is 
compliant  with  the  S-102  Functional  Diagram  Modeling  standard. 

8.  There  are  no  commonly  known  commercial  reliability  modeling  tools  available 
which  allow  feedback  to  be  included  in  the  model.  One  of  the  topics  in  this  study 
is  the  research  involved  in  defining  an  "enhanced  GO"  which  allows  feedback  to 
be  included  in  the  reliability  model.  GO  automatically  generates  the  reliability 
model  from  the  functional  model. 

9.  There  are  no  commonly  known  commercial  reliability  modeling  tools  available 
which  provide  output  in  a  format  which  is  compliant  with  an  industry  approved 
standard.  The  AIAA  S-102  Mission  Assurance  Standards  Working  Group  is 
interested  in  coordinating  the  further  development  of  an  "enhanced  GO"  to  create 
an  Open  Source  tool  which  provides  output  which  is  compliant  with  the  XML 
data  element  descriptions  defined  in  the  S-102  standards. 

10.  In  the  past  25  years,  very  few  commercial  reliability  analysis  tools  were 
developed  that  are  driven  by  functional  models  and  which  can  perform  multiple 
analyses.  One  of  these  tools  is  called  MultiLinx,  which  was  used  in  the  NASA 
Crew  Return  Vehicle  (CRV)  program  between  1998  and  2003.  This  tool  was  not 
marketed  in  the  public  domain  after  the  CRV  program  ended.  The  other  tool  is 
called  eXpress,  and  it  is  currently  used  by  many  companies  to  analyze  the 
testability  of  a  design.  The  eXpress  tool  is  not  intended  to  be  used  in  safety 
design  or  reliability  design  assessments.  An  "enhanced  GO"  could  become  the 
affordable  Open  Source  alternative  which  supports  both  safety  design  and 
reliability  design  assessments. 

E.  SCOPE 

The  scope  of  this  thesis  is  the  identification  and  validation  of  revisions  to  the  GO 
program  that  would  allow  concurrent  performance  of  safety  and  reliability  assessments 
on  dynamic  systems  that  include  output  feedback  control  functions.  This  study  will 
directly  support  Government  reviewed  and  approved  analyses  methodologies  which  can 
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then  be  shared  with  other  government  agencies  and  industry  partners.  This  revision  to 
GO  provides  a  no  cost  alternative  to  evaluate  the  combined  safety  and  reliability 
assessments  of  complex  systems. 

F.  CHAPTER  SUMMARY 

This  study  begins  with  a  literature  review  of  the  Event  Sequence  Analysis  GO 
program  and  then  a  review  of  Fortran  program  code.  Then  appropriate  test 
methodologies  of  sample  systems  and  the  generation  of  reports  were  developed  and 
performed.  The  results  of  these  tests  guided  the  development  of  the  program  code. 

Chapter  II  provides  a  review  of  the  GO  program  and  takes  the  reader  through  a 
history  of  the  development.  It  also  discusses  how  GO  is  used  by  engineers  for  analyses 
applications.  Chapter  III  discusses  the  systems  engineering  disciplines  of  system  safety 
and  reliability  engineering  and  details  how  the  disciplines  are  related  and  the  overlap 
which  exists  between  them.  Chapter  IV  delves  into  the  research  and  analyses  necessary 
to  incorporate  feedback  loops  into  a  model  for  use  with  the  GO  program.  Chapter  V 
describes  how  GO  may  be  utilized  by  both  reliability  and  system  safety  engineers  in  the 
performance  of  these  discipline  areas  as  a  common  analyses  tool.  Chapter  VI  presents 
conclusions  and  areas  for  further  research. 
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II.  EVENT  SEQUENCE  ANALYSIS  GO  PROGRAM  REVIEW 


A,  THE  DEVELOPMENT  OF  GO 

Bill  Gately,  Larry  Williams  and  Don  Stoddard,  while  working  for  Kaman 
Sciences  Corporation,  were  the  initial  developers  of  the  GO  program.  Their  work  began 
in  1967  with  funding  from  the  United  Stated  Army.  Since  1967  the  GO  codes  have  been 
developed  and  refined  continually.  Several  innovations,  improved  features  and  enhanced 
functionality  of  the  GO  program  were  developed  in  the  1970s,  including  data  consistency 
checks,  the  development  of  new  operators,  and  the  incorporation  of  a  data  type  called  a 
supertype.  The  supertype  operator  allows  a  user  to  create  complex  operators  that  can  be 
reused  when  developing  block  diagrams  and  translating  the  blocks  into  code. 

When  GO  was  first  developed,  the  use  and  acceptance  of  GO  was  widespread  as 
GO  allowed  for  unique  formulations  and  also  enabled  efficiencies  in  the  modeling 
approach.  As  the  number  of  users  increased  and  applications  of  the  GO  program  grew, 
Kaman  Sciences  Corporation  realized  a  need  to  continue  with  updates  and  modifications 
to  the  code.  Providing  support  and  maintaining  standardized  versions  became  a  necessity 
to  support  the  growing  number  of  experienced  users. 

Since  the  inception  of  GO  in  1967  there  have  been  24  versions  of  the  code  created 
as  identified  in  the  table  below. 
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VERSIONS  OF  THE  GO  CODES 

DATE 

NAME 

CHARACTERIZATION 

APR  68 

GOMAR68 

Eleven  Eogical  Operators,  Hash  Addressing 

JUN68 

GOJUN68 

— 

APR  69 

GOAP69 

Type  9  &  1 1  Kind  Data  Changed,  Sensitivity  Runs,  Eormat-free 
Data,  Modular  Programs,  Time  Points  up  to  9999  permitted 

MAY  69 

GOMAY69 

Use  of  two  computer  words  to  store  more  active  signals  and 
handle  larger  problems 

AUG  70 

GOAUG70 

— 

1971 

RANGO 

Randomized  GO,  Component  Beta  Distributions 

1972 

GOCHK72 

— 

APR  74 

GOAPR74 

Data  Checks,  Signal  Table 

1974 

XGO 

100  Active  Components,  Automatic  Signal  Deletion, 

Extensive  Error  Checking,  Perfect  Component  Case, 

Automatic  Array  Size  Optimization,  PMIN  Reset,  Types  5  & 

11  Combined 

1975 

Version  B 

— 

16  FEB  76 

Version  C 

New  Operators  11-15,  Multiple  Type  8  Delays,  GOl  Signal 
Table,  Developed  with  Public  Eunds 

26  APR  76 

Version  D 

Supertypes  GOl,  G02,  G03,  Printouts  Modified,  GOl  Signal 
Table,  Developed  with  Public  Eunds 

NOV  76 

Version  E 

— 

11  JAN  77 

Preliminary  Eault  Einder 

3  MAY  77 

GO 

Eault  Einder  SYSEILE,  EEl,  EE2 

30  NOV  77 

GO 

Types  15  &  17 

3  MAR  78 

Version  D  as  documented  for  EPRI,  Master  Program  GOEE, 
Data  Decks  Control  Sequence,  Alpha  Descriptors,  New  Type  4 

1  DEC  78 

GOEE 

Program  EG  and  G04  Created 

17  AUG  79 

GO 

Efficiency  Update,  New  Program  Structure,  Procedures  and 
CEISTS,  EIBRARY  GORUN 

1  OCT  79 

GO 

Effect  Evaluation  EEl,  EE2,  EE3 

20  MAR  80 

GO 

CDC  Version  Documented  for  EPRI 

20  MAY  80 

GO 

IBM  Version  Documented  for  B&R,  UP&E,  EPRI 

30  DEC  80 

GO 

IBM  Version  Enhanced  at  UCC,  Dallas,  Descriptors,  Eacility 
to  Alter  Array  Sizes,  Explanation  of  Use 

1  SEP  82 

KSCGO 

Version  1.0  Proprietary  to  KSC,  Both  VAX  and  CYBER 
Versions,  Developed  directly  from  GO  Version  C  1976 

Table  1.  Versions  of  the  GO  Codes  (From  Kaman  Sciences  Corp.,  1983). 
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Over  the  years,  GO  has  been  used  in  a  variety  of  systems  for  analyses. 
Disciplines  such  as  reliability,  availability,  safety  and  risk  assessment  have  benefited 
from  studies  with  GO  in  systems  such  as  satellites,  missiles,  conventional  and  nuclear 
munitions,  power  plants,  processing  plants  and  a  variety  of  other  systems.  GO  benefits 
the  user  by  the  way  it  handles  event  development  and  the  probability  of  occurrence 
associated  with  the  events. 

B.  GO  ANALYSES,  PROCEDURES  AND  OPERATORS 

To  better  understand  the  benefits  of  GO,  an  explanation  of  the  principles  of  the 
different  operators  and  how  to  encode  these  operators  into  a  model  for  analysis  is  needed. 
To  begin,  GO  operates  in  a  sequence  of  eight  programs.  These  programs  are  identified  as 
GOl,  G02,  G03,  FFl,  FF2,  EEl  EE2  and  EES.  This  study  focuses  on  the  application 
and  use  of  GOl,  G02  and  G03.  Some  explanatory  information  will  be  presented 
regarding  the  EE  and  EE  series,  but  no  detailed  information  will  be  provided.  The  GO 
sequence  1-3,  when  executed,  is  used  to  find  the  probabilities  of  the  different  systems 
states  of  the  modeled  system.  The  EE  series  is  a  fault  finder  sequence  of  analyses.  EE  1- 
2  is  used  to  determine  the  sets  of  operators  needed  which  will  cause  a  selected  event.  The 
EE  series  1-3,  which  is  not  being  evaluated  in  this  paper,  is  used  to  determine  the  effects 
on  probabilities  of  system  states  with  respect  to  uncertainties. 

In  each  of  the  series  of  analyses  (GO,  EE  or  EE),  the  programs  must  be  run  in  the 
numbered  order.  The  results  of  each  of  the  series  are  used  in  subsequent  programs.  One 
benefit  of  this  sequential  execution  of  the  program  is  that  once  the  data  sets  are  generated 
from  the  GO  series,  the  EE  or  EE  series  may  be  run  multiple  times  without  having  to  re¬ 
run  the  previous  series.  This  allows  for  different  events  to  be  analyzed  by  the  subsequent 
series  with  a  single  operation  of  a  previous  series. 

GOl,  G02  and  G03  operate  with  data  entered  by  the  user.  The  GOl  input  file 
contains  the  model  data  of  operators.  G02  contains  any  associated  probability 
information  related  to  the  operators.  G03  sets  analysis  parameters.  Each  of  these  input 
files  have  data  validation  checks  performed  when  the  associated  GO  execution  program 
is  executed.  The  checks  are  done  to  find  most  typing  or  logical  errors.  Although  the 

9 


programs  are  effective  in  finding  most  types  of  modeling  element  errors,  care  must  be  taken 
to  prevent  logical  errors  which  are  consistent  with  incorrect  parameter  inputs.  As  an 
example,  the  user  may  input  data  which  defines  two  states  for  a  signal  generator,  one  in 
which  the  signal  generated  is  a  value  of  “0”  80  percent  of  the  time  and  a  value  of  “1”  20 
percent  of  the  time.  If  the  user  incorrectly  assigns  the  percentages,  GO  will  perform  a  check 
which  will  determine  there  are  no  typing  or  logical  errors  for  the  entry.  Although  the  data  are 
logically  correct,  the  resulting  analyses  will  produce  accurate  results  for  the  inaccurately 
entered  data.  The  GO  program  will  first  process  the  operator  records  with  the  GO  1  program. 
GO  1  will  produce  an  operator  file  for  use  with  the  next  phase  of  the  program.  G02  will  read 
and  check  the  input  file  which  contains  the  “kind”  records  with  the  probability  data  and  will 
create  a  combined  operator  and  kind  file.  The  creators  of  the  GO  Program  use  the  term 
“kind”  to  define  references  to  different  types  or  “kinds”  of  modeled  elements.  For  example, 
a  switch  may  be  modeled  within  GO  and  depending  on  the  manufacturer  or  type,  the  switch 
may  have  different  probabilities  of  success  and  failure.  The  user  will  assign  a  kind  value  to 
each  individual  element  within  the  model  which  has  a  probability  of  success  and  failure 
defined.  If  when  modeling  a  system,  the  user  repeats  the  application  of  a  previously  defined 
or  kind  element,  the  kind  number  does  not  need  to  be  repeatedly  referenced  within  the  code. 
If  a  new  “kind”  element  is  used,  a  unique  kind  number  will  be  assigned  to  the  element  and 
the  associated  probability  data  defined  accordingly.  With  the  operator  and  kind  file  created, 
G03  is  used  to  evaluate  the  event  tree  and  will  create  a  file  which  contains  the  results  of  the 
analysis.  A  discussion  of  parameter  inputs  will  be  made  later  in  this  paper. 

GO  operates  with  seventeen  logical  operators  called  types  in  modeling  systems. 
These  types  are  used  so  that  systems  may  be  effectively  modeled  in  operation  or  with 
interactions  within  the  system.  A  list  of  the  seventeen  operators  is  shown  in  a  diagram  in 
Figure  1.  This  figure  shows  all  the  types  of  operators  and  also  shows  elements  of  operator 
inputs  which  would  be  required  when  modeling  the  element  in  the  GO  code.  Any  inputs  into 
an  operator  are  called  stimuli  and  given  the  nomenclature  of  Si,  S2,  ...,  Sn.  The  outputs  are 
called  responses  and  have  the  nomenclature  of  Ri,  R2,  ...,  Rn-  These  inputs  and  outputs  are 
random  variables.  When  using  GO  models,  the  random  variables  are  referred  to  as  signals. 
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Figure  1.  GO  Type  Operators  (From  Kaman  Seienees  Corp.,  1983). 

Each  operator  is  used  to  model  responses  from  equipment  or  of  human  actions 
within  a  system.  Each  of  these  operators  may  have  probabilities  associated  with  it  and 
will  evaluate  the  differing  random  variable  inputs  (S)  and  will  generate  the  appropriate 
response  (R). 

An  example  of  how  the  type  operators  are  used  follows.  A  type  1  operator  is  used 
to  logically  represent  an  element  that  will  either  perform  or  fail  to  perform  the  function 
given  a  correct  input  to  the  type  operator.  The  type  2  operator  is  an  OR  gate  and  it  will 
function  just  as  a  logical  OR  gate  and  will  generate  a  response  with  the  correct  inputs. 
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Type  1 

Two  State  Component 

Type  2 

OR  Gate 

Type  3 

Triggered  Generator 

Type  4 

Multiple  Signal  Generator 

Type  5 

Signal  Generator 

Type  6 

Normally  Open  Contact 

Type  7 

Normally  Closed  Contact 

Type  8 

Increment  Generator 

Type  9 

Function  Operator 

Type  10 

AND  Gate 

Type  1 1 

m  out  of  n  Gate 

Type  12 

Path  splitter 

Type  13 

General  Purpose,  Multiple  Input,  Multiple  Output  Operator 

Type  14 

Linear  Combination  Generator 

Type  15 

Value/Probability  Gate-Generator 

Type  16 

Actuated  Normally  Open  Contact 

Type  17 

Actuated  Normally  Closed  Contact 

Table  2.  GO  Type  Operators. 


To  suceessfully  create  a  model  in  GO,  the  user  must  complete  several  steps. 

1 .  Learn  how  the  system  is  configured  and  actually  operates. 

2.  Define  system  success  and  failure  criteria. 

3.  Identify  the  system  events  about  which  information  is  sought. 

4.  Represent  system  elements  with  standardized  GO  operators. 

5.  Combine  the  inputs  and  outputs  of  operators  representing  system  elements 
into  a  GO  model  portraying  successful  system  operation. 

6.  Obtain  the  probabilistic  data  for  component  response.  (Kaman  Sciences 
Corporation.,  &  Electric  Power  Research  Institute,  1983) 

The  GO  program  uses  a  methodology  of  translating  functional  or  block  diagrams 
into  a  code  and  then  generates  the  event  development  with  the  probability  of  success  and 
failure  associated  with  the  events.  To  best  illustrate  the  benefits  of  using  GO 
methodology,  first  an  understanding  of  what  the  industry  standard  definitions  of 
reliability  is  required. 

MIL-STD  721  defines  reliability  as:  (1)  The  duration  or  probability  of  failure- 
free  performance  under  stated  conditions  and  (2)  The  probability  that  an  item  can 
perform  its  intended  function  for  a  specified  interval  under  stated  conditions. 
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IEEE  defines  reliability  as  “the  eharaeteristie  of  an  item  expressed  by  the 
probability  that  it  will  perform  a  required  mission  under  stated  eonditions  for  a  stated 
mission  time”  (IEEE  Std  577-1976). 

GO  may  be  used  to  determine  a  system’s  reliability  performanee  measures.  To 
best  illustrate  the  ability  of  GO,  a  simple  example  will  be  used  whieh  demonstrates 
ealeulating  reliability  probabilities  using  a  representative  model  and  manual  ealeulations. 
A  familiar  model  is  one  in  whieh  a  eomparison  is  made  between  two  systems,  one  whieh 
operates  with  a  single  generator  and  the  other  with  two  generators.  Eunetional  diagrams 
of  a  single  system  and  a  two  generator  system  are  displayed  in  Eigures  2  and  3. 


Generator  A 


Generator  A 


This  system  starts  with  a  start  signal  with  a  probability  of  sueeess  of  98%  whieh 
leads  into  the  single  generator  in  Eigure  2  or  the  two  generators  of  Eigure  3.  Both 
generators  in  Eigure  3  are  positioned  in  parallel  providing  that  if  one  generator  were  to 
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fail,  the  second  generator  would  be  available  to  continue  the  operation.  All  generators  in 
both  Figures  2  and  3  have  a  probability  of  success  of  95%.  To  calculate  the  overall 
probability  of  success  for  the  system  in  Figure  2,  multiply  the  probability  of  success  of 
the  first  signal  times  the  probability  of  success  of  the  generator.  Multiplying  98%  and 
95%  yields  a  probability  of  success  of  93.1%.  When  two  components  operate  in  parallel, 
the  probability  calculation  changes.  The  calculation  of  the  parallel  generators  uses  the 
following  formula;  PA  +  PB  -  (PA  x  PB).  Substituting  the  values  of  95%  for  both 
generators  into  the  formula  results  in  0.95  +  0.95  -  (0.95  x  0.95)  which  results  in  1.90  - 
0.9025,  with  a  final  result  of  0.9975.  This  parallel  combination  of  generators  with  a  95% 
probability  of  success  for  both  generators  yields  an  overall  probability  of  success  of 
99.75%.  To  complete  the  calculation  of  a  two  generator  system  as  depicted  in  Figure  3, 
the  probability  of  success  for  the  first  signal  is  multiplied  by  the  probability  of  success  of 
the  parallel  generators.  Multiplying  98%  and  99.75  percent  yields  a  probability  of 
success  of  97.755%. 

The  results  of  the  manual  calculations  of  the  parallel  generator  system  will  now 
be  compared  to  the  results  of  a  two  generator  system  as  modeled  with  the  GO  program. 
Following  the  demonstration  of  the  results  generated  by  the  GO  program  is  an 
explanation  of  the  code  which  was  used  to  generate  the  GO  results.  To  begin.  Figure  4 
shows  how  a  functional  model  would  be  developed  for  use  with  GO.  The  reader  will 
note  the  numbering  used  in  each  of  the  symbols  used  in  Figure  4.  The  first  number  (or  in 
the  case  of  the  type  2  OR  gate,  the  only  number)  represents  the  type  of  operator  being 
used,  while  the  second  number  is  a  uniquely  assigned  identifier  called  a  kind  number. 
This  numbering  convention  helps  the  user  identify  and  track  the  components  when 
translating  from  a  graphical  or  schematic  model  to  the  code  which  will  be  used  as  inputs 
to  the  GO  program.  Additional  information  related  to  operator  types  and  kinds  will  be 
provided  in  more  detail  further  in  this  section. 
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Generator  B 


Generator  A 

Figure  4.  Simple  Reliability  Model  with  Two  Generators  as  Modeled  with  GO. 


GO  uses  several  different  operators  in  the  eomputer  eode  to  model  funetion  or 
behavior  of  the  elements  whieh  make  up  a  system.  The  first  signal  is  represented  by  a 
type  5  operator  whieh  is  a  signal  generator.  Generators  A  and  B  are  represented  by  a  type 
1  operator.  The  last  operator  used  in  this  model  is  a  type  2  whieh  is  an  OR  gate.  The  OR 
gate  reads  the  signals  present  on  the  inputs  and  aeeording  to  the  logie  of  an  OR  gate  will 
generate  an  output.  When  this  model  of  a  two  generator  system  operating  in  parallel  is 
proeessed  by  the  GO  program,  it  generates  a  table  of  results  whieh  is  presented  below  in 
Table  3,  where  the  numbers  shown  on  the  left  are  the  states  of  the  system  and  the 
numbers  along  the  top  of  the  table  are  the  signals.  State  1  is  the  operational  state  and 
State  4  shows  the  failed  state.  As  you  ean  see,  there  is  good  agreement  between  the 
operational  reliability  results  shown  under  signal  4  and  the  manual  ealeulation. 


VAL. 

1 

2 

3 

4 

1 

0.97999996 

0.93099993 

0.93099993 

0.97754997 

4 

0.02000000 

0.06900001 

0.06900001 

0.02245000 

Tables.  GO  Probability  of  Events. 
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c. 


PROGRAMMING  IN  GO 


Each  of  the  operator  types  requires  modeling  data  to  be  input  aeeording  to  the 
type  being  used.  Table  4  below  shows  eaeh  operator  type  and  the  different  modeling 
information  required  for  modeling  the  type  in  GO  eode. 


Data  1 

Operator  Type 

Data  2 

Data  3 

Data  4 

Data  5 

Data  6 

1 

K 

S 

R 

2 

0 

n 

Si . .  .Sn 

R 

3 

K 

S 

R 

4 

K 

n 

Rl...Rn 

5 

K 

R 

6 

K 

Si 

S2 

R 

7 

K 

Si 

S2 

R 

8 

K 

s 

R 

9 

K 

Si 

S2 

R 

10 

0 

n 

Si . .  .Sn 

R 

11 

m 

n 

Si . .  .Sn 

R 

12 

K 

S 

m 

Rl...Rn 

13 

K 

n 

Si . .  .Sn 

m 

Rl...Rn 

14 

K 

n 

Si . .  .Sn 

R 

15 

K 

S 

R 

16 

K 

Si 

S2 

R 

17 

K 

Si 

S2 

R 

K:  KIND  NUMBER 

S:  STIMULUS  (INPUT) 

R:  RESPONSE  (OUTPUT) 

Table  4.  GOl  Operator  Type  Data. 


Table  5  eontains  the  input  eode  and  data  whieh  were  used  to  ereate  the  GOl  input 
eode  as  represented  in  Figure  4. 
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Line  1 

G01  DATA  FOR  PARALLEL  RELIABILITY  SYSTEM 

Line  2 

. 4/ 

Line  3 

5  1  1  $  SIGNAL  GENERATOR 

Line  4 

1  2  1  2  $  GENERATOR  A 

Line  5 

1  3  1  3  $  GENERATOR  B 

Line  6 

202234$ OR  GATE 

Line  7 

0  1  2  3  4  $  FINAL  SIGNALS 

Line  8 

EOR 

Table  5.  GOl  Code  for  Parallel  Reliability  System. 


Line  1  identifies  the  title  of  the  GOl  eode.  Line  2  ean  be  edited  to  ehange  default 
system  parameters.  The  number  4  is  a  user  defined  value  identifying  what  value  the 
failure  state  for  the  model  should  be.  The  number  4  was  ehosen  in  this  model,  but  it 
eould  have  been  any  number  value  whieh  was  not  being  used  as  a  value  for  a  signal 
within  the  system.  For  the  purposes  of  this  study,  default  system  parameters  for  the  GO 
program  will  not  be  diseussed  other  than  the  assigned  failure  state  value,  using  the  system 
defaults  is  suffieient  for  the  purposes  of  analyses  of  GO  and  demonstrating  an  effeetive 
use  of  feedbaek  loops. 

Line  3  of  the  eode  deseribes  the  operator  as  a  type  5  operator  and  is  assigned  a 
kind  (K)  of  1,  a  response  (R)  of  1  and  following  the  $  eharaeter  is  a  deseription  or 
nomenelature  of  Generator.  The  kind  number  is  used  to  identify  the  unique 
eharaeteristies  of  this  type  operator.  In  addition  a  different  kind  number  should  be 
assigned  to  eaeh  operator  type  used  in  a  model  as  the  kind  number  is  linked  from  data 
ineluded  in  the  GOl  input  to  probability  data  whieh  would  be  ineluded  with  G02  input 
data.  If  multiple  type  5  operators  are  used  and  the  eharaeteristies  are  the  same  in  the  use 
of  this  type  within  the  eode,  only  one  type  5  operator  with  an  assigned  kind  would  need 
to  be  defined  within  the  GOl  input  eode.  On  the  other  hand  if  multiple  type  5  operators 
are  used  and  there  are  eharaeteristies  of  the  type  5  operator  that  differed  on  one  or  more 
operators,  then  a  unique  kind  number  would  be  assigned  to  eaeh  of  the  different  type 
operators.  The  response  (R)  of  1  identifies  that  a  single  response  will  be  generated  as  an 
output  signal.  The  nomenelature  following  the  $  symbol  identifies  this  type  5  operator  as 
a  generator. 
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Line  4  of  the  eode  deseribes  the  operator  as  a  type  1  operator  and  is  assigned  a 
kind  (K)  of  2,  a  stimulus  (S)  of  1,  a  response  (R)  of  2  and  following  the  $  character  is  a 
description  or  nomenclature  of  Generator  A.  The  stimulus  of  1  indicates  there  is  an  input 
stimulus  which  comes  from  signal  1  (as  shown  in  Figure  4);  the  response  (R)  of  2 
identifies  the  response  will  be  output  onto  signal  2.  The  nomenclature  following  the  $ 
symbol  identifies  this  operator  as  Generator  A. 

Line  5  of  the  code  describes  the  operator  as  a  type  1  operator  and  is  assigned  a 
kind  (K)  of  3,  a  stimulus  (S)  of  1,  a  response  (R)  of  3  and  following  the  $  character  is  a 
description  or  nomenclature  of  Generator  B.  The  stimulus  of  1  indicates  there  is  an  input 
stimulus  which  that  comes  from  signal  1;  the  response  (R)  of  3  identifies  the  response 
will  be  output  onto  signal  3.  The  nomenclature  following  the  $  symbol  identifies  this 
operator  as  Generator  B. 

Line  6  of  the  code  describes  the  operator  as  a  type  2  operator  and  is  assigned  a 
kind  (K)  of  0,  the  number  of  inputs  (n)  is  set  as  2,  a  stimulus  (SI)  of  2,  a  stimulus  (S2)  of 
3,  a  response  (R)  of  4  and  following  the  $  character  is  a  description  or  nomenclature  of 
OR  Gate.  This  kind  value  is  different  from  any  of  the  other  kind  values  which  have  been 
assigned  so  far.  OR  gates  as  well  as  AND  gates  (type  10)  when  used  in  GO  modeling  are 
considered  to  be  type  operators  with  perfect  kinds.  When  the  code  encounters  a  type 
operator  with  a  perfect  kind,  the  probability  of  success  for  the  operator  is  100  percent. 
The  data  type  n  of  2  identifies  this  OR  gate  has  two  stimulus  inputs.  The  stimulus  of  SI 
of  2  indicates  there  is  an  input  stimulus  which  will  come  from  signal  2,  the  stimulus  Sn 
(S2)  of  4  indicates  the  second  and  last  input  stimulus  will  come  from  signal  4.  The 
response  (R)  of  5  identifies  the  response  will  be  output  onto  signal  5.  The  nomenclature 
following  the  $  symbol  identifies  this  operator  as  an  OR  gate. 

Line  7  of  the  code  starts  with  a  zero  which  is  an  indicator  to  the  program  the  final 
signals  will  be  identified.  This  is  where  the  safety  or  reliability  engineer  will  identify 
which  signals  the  code  will  output  the  probability  information  associated  with  the 
individual  signals.  In  this  use,  all  signals  (1,  2,  3  and  4)  used  in  the  model  will  have  the 
associated  probability  data  output.  The  nomenclature  following  the  $  symbol  identifies 
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the  line  as  the  Final  Signals  line  of  eode.  Line  8  is  the  terminator  of  FOR.  This  is  an 
indicator  to  the  GO  program  the  inputs  of  GOl  are  complete  and  the  last  line  of  the 
record  has  been  reached. 

As  indicated  in  the  explanations  of  the  GOl  input  code,  there  are  probability  data 
associated  with  some  of  the  operators  used  in  GOl.  The  probability  data  are  included  in 
the  G02  input  fde  and  are  presented  in  Table  6. 
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Data  1 

Data  2 
Operator 
Type 

Data  3 

Data  4 

Data  5 

Data  6 

Data  7 

Data  8 

K 

1 

P. 

Pb 

K 

3 

Pg 

Pb 

Pp 

K 

4 

n 

m 

Vii...Vin 

Pi 

V21  ■  ■  ■V2n 

P2 

Vm1  ■  ■  ■  ^mn 

Pm 

K 

5 

n 

Vi 

Pl...Vn 

Pn 

K 

6 

Pg 

Pb 

Pp 

K 

7 

Pg 

Pb 

Pp 

K 

8 

n 

Di 

Pl...Dn 

Pn 

K 

9 

n 

Xi 

Y1...X, 

Yn 

K 

12 

m 

E 

Q. 

CL 

K 

13 

n 

m 

N 

VSii...VSnl 

Ml 

VRi...VR^ 

Pii 

VRi...VR, 

P  M11 

VSiN-  ■  -VSnN 

Mn 

VRi...VR, 

PlN 

VRi...VR^ 

P  MnN 

K 

14 

n 

ai...an 

3o 

K 

15 

Vi 

V2 

V3 

V4 

Pi 

P2 

K 

16 

Pi 

Pi 

P3 

K 

17 

Pi 

Pi 

P3 

K:  Kind  Number 

b:  Probability  Bad 

P:  Probability 

p:  Probability  Premature 

V:  Value 

n:  Number  of  Inputs;  0<=n<=10 

D:  Delay 

m:  Number  of  Outputs;  1<=m<=10 

g:  Probability  Good 

N:  Number  of  Output  Sets 

Table  6.  G02  Kind  Data. 


Table  7  contains  the  input  code  and  data  which  were  used  to  create  the  G02  input 
code  as  represented  in  Figure  4. 
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Line  1 

G02  DATA  FOR  PARALLEL  RELIABILITY  SYSTEM 

Line  2 

0/ 

Line  3 

1  5  2  1  0.98  4  0.02  $  SIGNAL  GENERATOR 

Line  4 

2  1  0.95  0.05  $  GENERATOR  A 

Line  5 

4  1  0.95  0.05  $  GENERATOR  B 

Table  7.  G02  Code  for  Parallel  Reliability  System. 


Line  1  identifies  the  title  of  the  G02  eode.  Line  2  ean  be  edited  to  change  default 
system  parameters.  Line  3  lists  Kind  1  for  the  type  5  operator.  The  number  2  represents 
the  n  number  of  outputs.  The  number  1  is  the  first  user  defined  value  VI  of  the  output 
signal  which  will  be  created  by  the  type  5  operator.  The  value  will  occur  with  a 
probability  percentage  PI  of  0.98.  The  next  number  is  the  value  V2  (Vn)  4,  which  is  for 
this  model  the  failure  value  chosen  by  the  user  in  Line  2  of  the  GOl  input  code.  The  V2 
value  will  occur  with  a  probability  of  0.02.  The  nomenclature  following  the  $  symbol 
identifies  this  operator  as  a  Generator. 

Although  each  of  the  remaining  lines  could  be  explained  number  by  number,  the 
intent  behind  this  information  was  to  familiarize  the  reader  with  the  method  by  which  a 
system  is  modeled  graphically  for  GO  and  how  the  graphical  information  is  then 
interpreted  into  the  GOl  and  G02  code.  The  remaining  lines  for  the  G02  table  follow 
the  same  pattern  as  described  in  Table  6  for  inputting  data  to  support  the  GO  program 
analyses.  For  reference,  the  code  for  G03  is  included  below  in  Table  8.  As  one  can  see, 
the  information  necessary  for  creating  the  G03  input  is  minimal.  Line  1  identifies  the 
title  of  the  G03  code.  Line  2  can  be  edited  to  change  the  default  system  parameters. 
Line  3  is  the  terminator  of  EOR. 


Line  1 

G03  DATA  FOR  PARALLEL  RELIABILITY  SYSTEM 

Line  2 

,„1,„,128/ 

Line  3 

EOR 

Table  8.  G03  Code  for  Parallel  Reliability  System. 


GO  has  the  capability  of  having  a  failure  state  value  assigned.  In  this  example, 

the  success  state  was  assigned  the  value  of  1,  the  failure  state  was  assigned  the  value  of  4. 

Referencing  Figure  3  above,  GO  produced  the  probability  of  success  for  each  of  the 

connectors  used  in  the  dual  generator  system.  After  the  OR  gate  operator,  signal  5  shows 
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a  probability  of  success  of  0.97754991  which  matches  the  probability  of  suceess  results 
determined  by  manual  ealeulations.  With  this  foundation  of  how  GO  can  be  used  as  an 
analysis  tool  in  place,  later  in  this  paper,  a  further  exploration  of  using  GO  to  analyze 
more  complex  systems  will  be  developed. 

In  addition  to  being  able  to  produee  tables  showing  probabilities  of  event  suceess 
and  failure,  GO  ean  perform  a  fault  finder  analysis.  GO  uses  algorithms  to  determine 
which  functional  or  component  failures  would  have  to  happen  for  an  identified  signal  to 
experienee  a  complete  failure.  An  example  of  a  fault  finder  analysis  on  signal  5  is  given 
below  in  Table  9. 


FAULT  SETS  OF  ORDER  1 

NO.  OP(STATE)  NAME 

1  1(1)  SIGNAL  GENERATOR 

FAULT  SETS  OF  ORDER  2 

NO.  OP(STATE)  NAME 

1  2(1)  GENERATOR  A  4(1)  GENERATOR  B 

NO  HIGHER  ORDER  FAULT  SETS  EXIST _ 

Table  9.  GO  Fault  Finder  Results. 

As  can  be  seen,  the  signal  generator  is  the  only  single  component  which  would 
result  in  a  complete  failure  at  signal  5.  If  two  failures  were  being  investigated,  there  is 
one  set  of  faults  which  would  result  in  failure,  both  generator  A  and  B  failing  would 
result  in  failure.  This  example  is  an  easy  one  to  evaluate  and  can  be  done  visually.  In 
more  complex  systems,  having  a  eomputer  perform  the  evaluation  is  useful  as  the 
analysis  will  be  performed  quickly  and  completely,  espeeially  if  fault  sets  of  higher 
orders  are  being  evaluated  or  in  cases  where  there  are  many  components. 

With  this  understanding  of  how  GO  operates  to  analyze  a  simple  reliability  model 
of  two  generators  the  next  step  is  to  introduce  the  reader  to  feedback  loops  and  how  GO 
can  be  utilized  to  perform  an  analyses  which  can  support  both  reliability  and  system 
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safety  assessments  with  a  single  eomputerized  tool.  With  the  introduction  of  feedback 
loops,  the  capabilities  of  GO  can  be  further  expanded  and  used  by  a  variety  of  users  in  the 
engineering  community. 
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III.  SYSTEMS  ENGINEERING  AND  THE  ROLE  OF  SYSTEM 

SAFETY 


A,  INTRODUCTION 

Systems  engineering  is  defined  by  the  International  Couneil  of  Systems 
Engineering  (INCOSE)  website  incose.org  as,  “Systems  Engineering  is  an 
interdisciplinary  approach  and  means  to  enable  the  realization  of  successful  systems.” 
One  of  the  mission  assurance  elements  within  systems  engineering  is  the  engineering 
discipline  of  system  safety.  MIL-STD-882C  defines  safety  as,  “Ereedom  from  those 
conditions  that  can  cause  death,  injury,  occupational  illness,  or  damage  to  or  loss  of 
equipment  or  property,  or  damage  to  the  environment.”  MIL-STD-882C  defines  system 
safety  as,  “The  application  of  engineering  and  management  principles,  criteria,  and 
techniques  to  optimize  all  aspects  of  safety  within  the  constraints  of  operational 
effectiveness,  time  and  cost  throughout  all  phases  of  the  system  life  cycle.”  Often  there 
is  a  misconception  that  system  safety  as  an  engineering  entity  is  focused  on  protecting 
personnel  from  accidents  by  focusing  on  slips,  trips,  falls,  and  toxic  chemicals/materials. 
In  fact  system  safety  incorporates  the  necessary  requirements  into  product  design  to  allow 
for  safety  to  be  an  integral  part  of  the  design  process  and  process  hazard  avoidance  at 
every  indenture  level  of  the  system. 

System  safety,  as  an  engineering  discipline,  contributes  to  systems  engineering 
objectives  by  applying  a  set  of  safety  design  requirements  throughout  all  life  cycle  phases 
of  a  system,  whether  it  is  design,  manufacturing,  sustainment  or  at  the  end  of  service  life. 
Safety  design  requirements  follow  a  pre-established  order  of  precedence.  Eor  example, 
MIL-STD-882C  imposes  a  four-level  order  of  precedence  for  safety  design  requirements. 
Eirst  in  the  MIL-STD-882C  order  of  precedence  is  designing  for  minimum  risk,  which  is 
accomplished  by  eliminating  hazards  through  design  and  by  reducing  risk  to  acceptable 
levels  throughout  the  design  selection.  Second  in  the  MIL-STD-882C  order  of 
precedence  is  the  incorporation  of  safety  devices,  e.g.,  power  circuitry  fuses  and  anomaly 
detection  and  response  (ADR)  software  for  fast-acting  failure  modes.  Third  in  the  MIL- 
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STD-882C  order  of  precedence  is  providing  warning  devices.  Finally,  fourth  in  the  MIL- 
STD-882C  order  of  precedence  is  developing  appropriate  procedures  and  training. 
System  safety  also  levies  requirements  on  the  system  design  philosophy  in  terms  of  fault 
tolerance  requirements.  For  example,  MIL-STD-882C  Appendix  C,  Section  70.1.1a, 
requires  mission-critical  system  functions  to  be  able  to  continue  operating  after  any  single 
fault  occurs  within  the  system  or  within  an  external  entity  controlling  the  system.  MIL- 
STD-882C  Appendix  C,  Section  70.1.1b  also  requires  safety-critical  system  functions  to 
be  able  to  continue  operating  after  any  dual  independent  faults  occur  within  the  system 
and/or  within  an  external  entity  controlling  the  system.  Due  to  the  wide-spread  practice 
of  allowing  high  unit-value  system  designs,  e.g.,  satellites  and  military  aircraft,  to 
minimize  rather  than  eliminate  all  single-point  failure  modes  and  using  mission-critical 
equipment  for  system  “safing”  functions,  the  practicality  of  verifying  dual-fault  tolerance 
is  often  limited  to  evaluating  the  failure  of  one  mission-critical  hardware,  software,  or 
procedural  item  and  the  failure  of  one  responding  safety-critical  software  item,  e.g.,  an 
ADR  algorithm.  Due  to  multiple  failures  being  involved,  the  safety-critical  software  item 
can  be  identified  using  the  GO  program.  Fault  Tree  Analysis,  or  an  equivalent 
“deductive”  analysis  methodology.  Then  software  hazard  analysis  or  software  FMECA 
is  performed  to  identify  design,  processing,  or  operating  features  that  can  either  mitigate 
the  root  causes  or  compensate  for  the  effects  of  each  software  functional  failure  mode. 

B,  OVERLAP  BETWEEN  SYSTEM  SAFETY  AND  SYSTEM  RELIABILITY 

ENGINEERING 

In  the  last  chapter,  a  simple  example  of  how  system  reliability  is  calculated  was 
presented.  In  this  chapter,  an  explanation  of  the  overlap  which  exists  between  system 
safety  and  reliability  engineering  will  be  provided.  As  discussed  previously,  system 
safety  contributes  to  systems  engineering  through  design  influence  and  process  hazard 
avoidance.  For  complex  high  unit-value  systems  even  a  minor  design  change  can  have  a 
large  impact  on  the  cost  and  performance  of  the  system.  One  of  many  systems 
engineering  elements  that  contribute  to  the  system  design  definition  is  reliability 
engineering.  If  a  system  has  a  requirement  for  the  generation  of  power  to  have  a  mission 
reliability  of  95%,  the  example  single  generator  design  configuration  would  not  satisfy 
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the  reliability  requirement,  but  the  two  generator  design  configuration  would.  If  the  same 
system  has  a  system  safety  requirement  for  the  generation  of  power  to  be  dual-fault  tolerant, 
the  two  generator  design  configuration  would  not  satisfy  the  system  safety  requirement.  One 
possible  solution  to  the  problem  just  described  would  be  to  introduce  a  third  generator  into 
the  system. 

It  is  important  to  emphasize  that  there  are  often  overlapping  requirements  between 
the  disciplines  of  system  safety  and  reliability  engineering.  Aside  from  cost  and 
performance,  there  are  other  design  attributes  which  can  be  influenced  by  a  design  change. 
The  reliability  engineer  will  focus  on  the  system  design  satisfying  its  mission  reliability 
requirement  through  allocation  of  the  system  level  reliability  requirement  to  the  subsystem 
level,  assembly  level,  etc.  In  contrast,  the  system  safety  engineer  will  focus  on  the  system 
design  satisfying  its  dual-fault  tolerance  requirement  for  all  safety-critical  functions  through 
reduction  of  the  system  design  to  a  set  of  safety-critical  functions.  There  is  often  a  conflict 
between  the  reliability  engineering  effort  and  system  safety  effort,  because  the  former  has 
“flexibility”  at  the  subsystem  and  lower  levels  as  long  as  the  system  level  design  meets  its 
quantitative  requirements,  while  the  latter  must  rigidly  control  “hazard  risk”  at  relatively  low 
functional  hardware/software  component  levels.  For  example,  hardware/software  component 
single-point-failure-modes  (SPFMs)  have  a  greater  impact  on  safety-critical  design 
requirements  (e.g.,  dual-fault  tolerance)  than  on  mission  reliability-critical  design 
requirements  (e.g.,  single-fault  tolerance).  However,  reliability  engineers  and  system  safety 
engineers  are  responsible  for  identifying  and  controlling  some  of  the  same  types  of  faults, 
such  as  SPFMs.  So  there  is  a  great  deal  of  potential  benefit  from  using  common  tools  such  as 
the  GO  program,  among  different  engineering  disciplines.  These  common  tools  would  allow 
a  complex  system  design  to  by  simultaneously  analyzed  quickly  in  different  ways  and  for 
detailed  reports  to  be  automatically  generated  to  yield  multiple  solutions  for  further 
optimization  or  for  identifying  potential  trade  space  within  the  system.  With  the  increasing 
complexity  of  systems  as  technology  advances,  the  need  for  the  different  engineering 
disciplines  to  work  cooperatively  to  satisfy  system  requirements  becomes  more  important. 
As  such,  the  use  of  more  common,  powerful  and  robust  computer  aided  tools  becomes  more 
important  as  well. 
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c. 


CHAPTER  SUMMARY 


There  are  many  aspects  within  the  disciplines  of  system  safety  and  reliability 
which  overlap.  The  example  presented  illustrates  the  relationship  between  the  two 
disciplines  and  how  the  design  implementation  of  one  discipline  may  impact  the  other 
discipline  in  meeting  an  important  requirement.  The  ability  to  use  a  common  set  of  tools 
between  the  two  disciplines  would  be  helpful  as  each  would  receive  benefit  from  tools 
which  could  be  universally  used,  allowing  for  potential  savings  in  work  efforts  and 
efficiencies  in  operations  as  a  result. 

The  GO  program  is  a  tool  that  can  be  used  for  both  system  safety  and  reliability  to 
analyze  system  design  to  ensure  all  requirements  are  being  met  and  to  assess  the  degree 
to  which  each  requirement  has  been  met.  A  fully  defined  process  for  incorporating 
feedback  loops  is  necessary,  however,  so  that  GO  can  be  fully  support  the  needs  of 
reliability  engineers.  Without  a  defined  process  for  incorporating  feedback  loops,  GO 
would  continue  to  be  beneficial  for  system  safety  engineers  but  would  have  limited 
benefit  for  reliability  engineers.  The  limited  benefit  stems  from  the  difficulty  involved 
with  using  computer  code  to  analyze  feedback  loops.  When  using  a  computer  to  analyze 
a  circuit  or  a  system,  the  calculations  to  arrive  at  a  deterministic  result  are  performed  as 
the  code  processes  through  the  system  path.  When  feedback  is  involved,  this  causes  a 
path,  which  had  previously  been  analyzed,  to  require  another  iteration  in  the  calculation 
process.  Unfortunately,  due  to  how  reliability  or  probability  calculations  are  performed, 
the  previously  used  probability  values  can  not  be  used  and  therefore  require  different 
calculations  to  arrive  at  the  correct  reliability  or  probability  calculations.  Currently 
reliability  engineers  typically  use  two  separate  models  for  determining  the  reliability  of  a 
system  that  has  feedback.  One  model  would  be  for  the  system  and  a  separate  model 
would  be  used  to  estimate  the  reliability  involving  the  feedback  loops.  After  the  estimate 
was  completed,  the  reliability  engineer  would  then  attempt  to  merge  the  two  models  in 
the  best  manner  possible  based  on  the  engineer’s  own  experience.  One  of  the  difficulties 
faced  when  separate  models  are  created  is  the  merging  of  the  models.  When  a  system  is 
split  to  take  into  account  different  methods  of  modeling  interactions  and  the  associated 

probabilities  of  the  interactions,  there  is  the  possibility  of  introducing  error  when  the 
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separate  models  are  then  combined.  In  addition,  there  are  several  different  methods 
available  for  modeling  interactions.  One  engineer  may  choose  one  method,  while  another 
engineer  a  different  one.  Given  the  opportunity  for  subjective  choices  to  be  made  when 
modeling  probabilities,  this  creates  the  opportunity  for  two  qualified  engineers  to  model 
the  same  system  and  come  up  with  different  results  based  on  the  modeling  methodologies 
chosen.  If  GO  could  be  used  with  feedback  loops  incorporated  into  the  functional  model, 
there  would  be  no  need  to  have  two  separate  models  created  and  then  merged  by  the 
reliability  engineer.  In  the  next  chapter  of  this  paper,  a  fully  defined  methodology  for 
incorporating  feedback  loops  into  a  functional  design  is  documented. 
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IV.  RESEARCH  ANALYSIS 


A,  INTRODUCTION 

In  this  section,  the  author  will  present  a  description  of  a  single  model  based  on  an 
example  problem,  describe  the  functional  behavior  and  describe  how  to  incorporate  a 
single  feedback  loop  into  the  GO  program  for  analysis.  Once  the  single  model  has  been 
described  and  each  of  the  elements  within  the  model  documented,  this  paper  will  next 
introduce  a  standard  model  with  two  feedback  loops  as  well  as  a  complex  model  with 
three  feedback  loops.  Each  of  these  examples  will  serve  to  demonstrate  what  steps  would 
be  taken  by  an  engineer  to  follow  a  standard  methodology  for  performing  reliability  and 
safety  analyses  on  systems. 

Monte  Carlo  simulations  for  each  of  the  examples  were  created.  Monte  Carlo 
simulations  were  chosen  as  a  tool  to  use  to  validate  the  results  of  the  GO  program  as 
Blanchard  and  Fabrycky  state,  ’’Models  and  their  manipulation  (the  process  of 
simulation)  are  useful  tools  in  systems  analysis.”  They  further  state,  “A  mathematical 
model  employs  the  language  of  mathematics  and,  like  other  models,  may  be  a  description 
and  then  an  explanation  of  the  system  it  represents  (Blanchard  and  Fabrycky,  2006).  The 
Monte  Carlo  simulation  was  a  natural  selection  to  use  for  validating  the  model 
represented  within  the  GO  modeled  code  as  GO  is  a  logical  and  mathematical  analyses 
application. 

B,  EXAMPLE  PROBLEM 

An  engineer  may  be  faced  with  a  problem  of  how  to  model  the  behavior  of  a 
person  faced  with  a  set  of  actions  to  be  taken.  Each  of  the  actions  which  could  be  taken 
will  be  called  tasks.  In  the  single  model,  the  system  is  made  up  of  tasks  A,  B  and  C. 
Each  task  has  a  probability  of  success  and  failure.  The  person  performing  the  tasks  has  a 
number  of  choices  which  can  be  taken  in  accomplishing  the  tasks.  In  all  cases,  task  A  is 
to  be  accomplished  first.  In  this  study,  it  is  preferred  but  not  required  that  the  tasks  are 
accomplished  in  alphabetical  order.  The  preferred  order  would  follow  that  A  is 
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accomplished,  then  task  B  and  with  sueeessful  aeeomplishment  of  task  B,  then  task  C 
would  be  performed.  Alternatively,  task  A  eould  be  performed  and  the  ehoiee  could  be 
made  to  skip  task  B  and  perform  task  C.  Last,  task  A  eould  be  performed,  task  B 
attempted  and  a  failure  of  task  B  experienced,  whieh  would  then  result  in  the  person 
returning  to  perform  task  A  again  and  then  perform  task  C.  In  the  single  model,  if  a  task 
failure  is  experieneed  at  task  A  or  task  C,  the  system  will  result  in  a  failure.  It  is 
important  to  note  that  this  model  eould  have  been  designed  to  allow  the  first  task  to  be 
task  B  or  task  C,  but  allowing  this  eompheates  the  model  and  does  not  aid  in  the  purpose 
of  demonstrating  a  methodology  for  ineorporating  feedbaek  loops.  The  objeetive  of  this 
study  was  to  determine  a  methodology  for  implementing  feedbaek  loops  into  a  logieal, 
automated,  eomputer  assisted  probability  assessment  tool.  There  is  not  an  intention  to 
provide  for  a  study  whieh  analyzes  a  eomprehensive  and  exhaustive  list  of  possible  task 
path  eombinations.  A  feedback  loop  used  in  the  context  of  this  study  represents  an 
opportunity  for  an  aetion  which  could  be  performed  more  than  onee  and  ean  be  aceounted 
for  via  the  feedbaek  loop  methodology.  In  the  ease  of  this  study,  each  task  path  which 
can  be  aeeomplished  ean  be  traeed  out  in  the  funetional  bloek  diagrams  and  the  GO 
models. 

Figures  5,  6,  and  7  show  the  three  models  eaeh  in  inereasing  eomplexity.  These 
are  funetional  models  and,  in  the  next  section,  will  be  shown  in  eorresponding  funetional 
bloek  diagrams  that  were  used  to  ereate  models  with  the  GO  program.  As  stated 
previously,  the  single  model  has  tasks  A,  B  and  C.  The  standard  model  adds  a  task  D  and 
the  complex  model  adds  tasks  D  and  E. 
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Go  to  C 

Figure  5.  Functional  Block  Diagram  of  Single  Model  with  Tasks  A,  B  and  C. 
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Figure  6.  Functional  Block  Diagram  of  Standard  Model  with  Tasks  A,  B,  C  and  D. 
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13 


Figure  7.  Functional  Block  Diagram  of  Complex  Model  with  Tasks  A,  B,  C,  D  and  E. 


C.  EVENT  SEQUENCE  ANALYSIS  (GO  PROGRAM)  SINGLE  FEEDBACK 
LOOP  IMPLEMENTATION 

With  an  understanding  of  how  to  use  the  GO  program,  an  engineer  can  take  a 
functional  block  diagram  and  select  the  appropriate  operators  so  that  a  representative 
model  may  be  created  to  be  analyzed  by  GO.  In  the  case  of  the  single  model,  the  GO 
diagram  is  represented  in  Figure  8  below. 
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Task  B 
Fails; 

A  to  C 


Figure  8.  GO  Diagram  of  Single  Model  with  Tasks  A,  B,  and  C. 


A  summary  table  whieh  shows  all  of  the  signals  from  1  through  1 1  and  the  values 
whieh  ean  be  found  on  the  signals  is  presented  in  Table  10.  Eaeh  step  shown  in  Figure  8 
will  be  explained  in  the  paragraphs  below  detailing  how  this  GO  model  is  structured  and 
operates. 


Signal: 

1 

2 

6 

7 

9 

10 

11 

Values: 

0/10 

1/10 

3/10 

4/10 

4/10 

1/3/4/10 

1/3/4/10 

Table  10.  GO  Diagram  of  Single  Model  Signals  and  Values  Output. 


Task  A  in  the  single  model  is  represented  by  a  type  4  operator  which  is  a  value 
generator.  If  task  A  is  successful  a  value  of  zero  or  one  is  generated.  If  task  A  is  not 
successful  or  a  path  is  not  chosen,  a  value  of  ten  is  generated.  Signal  1  will  either  have  a 
value  of  zero  or  ten.  Signal  2  with  either  have  a  value  of  one  or  ten  or  both  signal  1  and  2 
will  have  a  value  of  ten  according  to  the  assigned  probability  of  success  and  failure  for 
task  A. 

Task  B  and  task  C  are  both  represented  by  a  type  1  operator.  If  task  B  is  selected 
and  task  B  is  successful,  it  will  pass  a  value  of  zero  to  signal  5.  There  is  an  operator 
which  follows  task  B  which  is  a  type  15  operator.  This  operator  may  change  the  value 
which  is  present  at  signal  5.  If  a  value  of  zero  is  present,  the  type  15  operator  will  always 
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change  the  value  from  zero  to  three.  If  the  value  is  ten,  a  value  of  ten  is  passed  to  signal 
6.  The  reason  this  type  15  operator  is  ineluded  is  to  allow  for  a  trace  of  values  to  be 
established  as  the  model  progresses  from  task  A  through  task  C.  This  model  could  have 
been  made  with  just  a  sueeess  or  failure  value  being  used,  however,  to  better  demonstrate 
how  this  model  works  for  traceability,  the  type  15  operator  was  added  and  the  value 
changed. 

A  type  5  operator  is  used  in  this  model  as  the  methodology  to  represent  the 
beginning  of  the  path  in  whieh  task  B  is  not  suceessful  and  the  person  has  returned  to  task 
A  and  then  proeeeded  directly  from  task  A  to  task  C.  The  path  task  A  to  task  C  already 
exists,  but  the  event  of  task  B  failing  is  a  feedback  that  needs  to  be  modeled  separately 
from  the  first  order  ehoiee  of  selecting  task  A  and  then  task  C.  The  type  5  operator 
generates  a  value  of  zero  if  it  is  successful  aceording  to  the  assigned  probability  of 
sueeess  and  a  value  of  ten  otherwise.  A  type  9  operator  ineorporates  the  logie  neeessary 
for  the  system  to  reeognize  if  task  B  has  failed  and  if  the  ehoiee  has  been  made  to 
perform  task  A  and  then  go  to  task  C.  The  type  9  will  apply  the  assigned  logic  and 
according  to  the  logie  will  either  pass  the  value  of  four,  indieating  that  task  B  had  failed 
and  the  ehoiee  was  made  to  return  to  task  A  and  then  attempt  task  C  or  the  value  of  ten 
indicating  the  signal  path  9  is  failed.  Either  a  value  of  four  or  a  value  of  ten  will  be 
passed  by  the  type  9  operator  to  signal  9. 

Task  A  to  task  B  follow  the  signal  path  of  1,  5  then  6.  Task  A  to  task  C  is  path  2. 
The  feedbaek  loop  of  ‘B  fails,  go  back  to  perform  A  and  then  C’  is  signal  path  7  then  9. 
Signals  2,  6  and  9  are  all  connected  to  an  OR  gate  with  the  output  of  the  OR  gate 
connected  to  signal  path  10.  The  OR  gate  reads  the  signals  present  and  passes  the  lowest 
value  signal  on  to  the  task  C  operator,  which  is  the  final  operator  in  this  model  and  is 
signal  1 1 .  The  type  1  operator  representing  task  C  will  succeed  or  fail  aecording  to  the 
probabilities  assoeiated  with  the  task.  When  this  system  is  processed  by  the  GO  program, 
it  generates  a  table  of  results.  These  results  are  the  probability  of  event  success  and 
failure  and  are  presented  below  in  Table  1 1 . 
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Value: 

1 

2 

5 

6 

0 

0.80000007 

0.00000000 

0.64000005 

0.00000000 

1 

0.00000000 

0.10000001 

0.00000000 

0.00000000 

3 

0.00000000 

0.00000000 

0.00000000 

0.64000005 

4 

0.00000000 

0.00000000 

0.00000000 

0.00000000 

10 

0.20000002 

0.90000004 

0.36000001 

0.36000001 

Value: 

7 

9 

10 

11 

0 

0.00000000 

0.00000000 

0.00000000 

0.00000000 

1 

0.00000000 

0.00000000 

0.10000001 

0.08000001 

3 

0.00000000 

0.00000000 

0.64000005 

0.51200002 

4 

0.80000007 

0.28800002 

0.20800000 

0.16640002 

10 

0.20000002 

0.71200002 

0.05200000 

0.24160000 

Table  11.  GO  Probability  of  Events  for  Single  Model. 

This  study  is  not  meant  to  be  a  tutorial  on  how  to  use  the  GO  program,  but  at  the 
same  time  it  is  often  benefieial  to  see  the  eode  which  was  used  to  produce  the  results  as 
shown  in  Table  12.  The  GO  program  uses  several  input  files  which  are  read  in 
individually  and  processed  serially.  There  are  two  input  files  with  the  bulk  of 
information  required  to  be  read  in  and  processed  by  GO.  The  first  file  is  named  GOl  and 
the  second  is  G02.  The  code  for  GO  1  and  G02  are  included  in  Table  12  below. 


G01  DATA  FOR  FEEDBACK  LOOP 

4  1  2  1  2  $  FIRST  LVL  A 

1  5  1  5  $  SECOND  LVL  B 

15  8  5  6  $  VALUE  CHANGER 

5  2  7  $  SECOND  LVL  B 

9  6  6  7  9  $  TYPE  9  MODEL1 

203269  10  $  OR  GATE 

1  5  10  11  $  THIRD  LVLC 

0  1  2  567  9  10  11$  FINAL  SIGNALS 

G02  DATA  FOR  FEEDBACK  LOOP 

1  4  2  3  0  10  0.8 

10  1  0.1 

10  10  0.1  $  FIRST  LVL  A 

8  153  10  0  00  1  $VALUECHANGER 

2  5  2  4  0.8  10  0.2  $  B  FAIL  INPUT 

6  9  1-6-6$  TYPE  9  MODEL1 

5  1  0.8  0.2  $  SECOND  LVL  B/C 

Table  12.  GOl  and  G02  Code  Input  Files  for  Single  Model. 
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The  probabilities  of  suecess  and  failure  for  each  of  the  operator  types  are 
contained  within  the  G02  code.  Of  interest  in  this  single  model  is  that  task  A  has  a 
probability  of  success  to  go  directly  to  task  B  set  at  80%,  which  fits  the  description  the 
preferred  path  to  take  is  A,  then  B  then  C.  The  path  to  go  from  task  A  to  task  C  is  set  at 
10%  and  there  is  a  failure  probability  of  task  A  set  at  10%.  Both  task  B  and  task  C  are 
represented  by  the  type  1  operator  and  they  both  have  a  probability  of  success  equal  to 
80%.  The  type  15  operator  will  always  have  an  output  value  of  either  three  or  ten  and 
this  is  dependent  strictly  on  the  input  to  the  type  15  operator.  The  type  5  operator  has  a 
probability  of  success  equal  to  80%.  The  type  2  operator,  which  is  the  OR  gate,  will 
always  operate  100  percent  of  the  time.  There  is  no  probability  of  success  associated 
with  this  operator  type.  The  last  operator  to  discuss  is  the  type  9  operator  and  the  logic 
associated  with  it.  In  the  G02  subprogram,  the  logic  required  by  the  GO  program  to  use 
the  type  9  operator  is  identified  by  the  number  1  and  the  pair  of  numbers,  -6  and  -6. 
Without  going  into  the  specific  algorithm,  the  engineer  who  programs  the  code  performs 
a  set  of  additions  and  subtractions  to  determine  under  which  conditions  and  which 
outputs  will  be  allowed  to  be  passed  to  signal  9.  Once  the  algorithm  is  mastered,  the 
engineer  will  find  the  type  9  operator  very  useful. 

The  last  item  to  discuss  in  this  section  is  the  interpretation  of  the  results.  Table  1 1 
contains  the  results  which  will  be  examined  are  the  probabilities  of  events  found  on 
signal  1 1 .  With  a  working  knowledge  of  the  single  feedback  system,  one  can  predict  the 
values.  For  value  zero,  there  is  a  0%  probability  of  this  event  at  signal  11.  This  is  easily 
confirmed  knowing  that  value  zero  only  appears  on  signal  1  and  does  not  propagate 
further.  Value  one  happens  8%  of  the  time  and  makes  sense  as  it  is  a  first  level  choice 
between  taking  the  preferred  path  the  alternate  path  directly  to  task  C.  It  should  be 
expected  that  value  three  would  occur  most  often  as  it  represents  the  preferred  path. 
Value  four  is  16.64%  which  represents  the  probability  of  task  B  failing  and  then  returning 
back  to  task  A  and  then  attempting  task  C.  This  system  as  designed  and  with  the 
probabilities  of  success  and  failure  associated  with  it  have  an  overall  failure  rate  as 
expressed  in  value  ten  of  24. 16%. 
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To  independently  support  the  results  are  as  ealeulated  by  the  GO  program,  a 
Monte  Carlo  simulation  was  set  up  with  Mierosoft  Exeel  Random  numbers  were 
generated  and  propagated  into  a  table.  The  same  logie  derived  from  the  funetional 
diagram  was  applied  to  the  Monte  Carlo  Simulation.  A  step  by  step  explanation  of  the 
GO  eode  and  the  relationship  of  GO  eode  to  eaeh  of  the  Exeel  eells  eode  used  in  the 
simulation  is  explained  in  Appendix  A.  The  Monte  Carlo  simulation  ean  be  found  in 
Appendix  B.  Note  the  Monte  Carlo  simulation  and  results  ineluded  in  Appendix  B  have 
been  truneated  to  only  inelude  the  first  five  rows  of  randomly  generated  inputs.  Eor  the 
interested  reader,  inereasing  the  elements  to  a  higher  number  for  inereased  fidelity  of  the 
random  results  ean  be  aeeomplished  by  ereating  a  one-variable  data  table  with  the 
number  of  experiments  desired.  Instruetions  on  ereating  this  one-variable  data  table  may 
be  found  by  using  the  Exeel  help  funetion  or  index  tool  and  following  the  instruetions  for 
ereating  one-variable  data  tables.  Note  that  in  this  partieular  table  set  up,  the  table  is  row- 
oriented. 

D,  EVENT  SEQUENCE  ANALYSIS  (GO  PROGRAM)  STANDARD 

FEEDBACK  LOOP  IMPLEMENTATION 

Building  on  the  foundation  of  a  simple  feedbaek  loop,  a  standard  feedbaek  loop 
ineludes  two  opportunities  for  feedbaeks  to  be  looped  into  the  analysis  of  a  system.  The 
funetional  bloek  diagram  and  appropriate  operators  of  this  representative  model  is 
presented  in  the  GO  diagram  in  Figure  9  below. 
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Figure  9.  GO  Diagram  of  the  Standard  Model  with  Tasks  A,  B,  C  and  D. 

Less  detail  will  be  presented  in  the  operation  of  this  model  as  the  behavior  of  the 
model  is  largely  similar  to  that  of  the  simple  model.  The  key  differences  between  this 
model  and  that  of  the  simple  model  is  this  model  adds  an  additional  task,  task  D  and  also 
has  a  second  feedback  to  consider,  namely  what  options  become  additionally  available 
when  a  task  is  added.  With  these  changes,  additional  operators  needed  to  be  added  as 
well  as  operator  types  changed  to  allow  for  a  representative  model  to  be  created.  Task  A 
has  three  paths,  the  additional  path  to  take  is  one  from  task  A  directly  to  task  D.  A  choice 
can  be  made  after  accomplishing  task  B  to  go  directly  to  task  D.  If  task  B  fails,  there  are 
now  two  options,  either  accomplish  task  A  and  go  to  task  C  or  accomplishment  of  task  A 
and  go  to  task  D.  Last,  there  is  now  another  option  should  task  C  fail.  If  task  C  should 
fail,  there  is  now  an  option  to  return  to  task  A  and  the  go  directly  to  task  D. 

Although  each  change  made  in  the  diagram  could  be  discussed,  the  selection  of 
which  operators  to  use  in  the  creation  of  a  model  is  largely  a  choice  made  by  the 
engineer.  The  important  information  to  highlight  is  to  identify  what  operator  types  are 
required  to  correctly  model  the  feedback  loop  implementation.  Of  note,  the  type  5 
operator  is  added  to  this  model  prior  to  the  single  input  needed  to  model  the  failure  of 
task  C  and  the  choice  to  perform  task  A  and  then  go  to  task  D.  The  change  of  the 
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operator  type  for  task  B  failing  from  a  type  5  to  a  type  4  is  made  to  satisfy  the  need  to 
have  multiple  task  choiees  available  after  task  B.  The  additions  and  uses  of  the  type  9 
operators  in  this  model  are  the  same  as  in  the  simple  model.  The  last  operators  added  are 
the  OR  gates  used  to  reeeive  all  possible  paths  which  can  be  taken  prior  to  task  D  as  well 
as  the  type  1  operator  used  to  model  task  D. 

As  was  provided  for  the  single  model,  the  standard  model  also  had  a  Monte  Carlo 
simulation  set  up  with  Microsoft  Excel  ™.  Random  numbers  were  generated  and 
propagated  into  a  table.  The  same  logic  which  is  applied  to  the  functional  diagram  was 
applied  to  the  Monte  Carlo  Simulation.  This  simulation  can  be  found  in  Appendix  B. 
The  Monte  Carlo  simulation  for  the  various  signals  and  the  GO  results  match  very  well 
for  this  model  also. 

E.  EVENT  SEQUENCE  ANALYSIS  (GO  PROGRAM)  COMPLEX 

FEEDBACK  LOOP  IMPLEMENTATION 

Continuing  with  the  manner  of  presentation  from  section  B,  a  complex  feedback 
loop  model  is  introduced.  The  functional  block  diagram  and  appropriate  operators  of  this 
representative  model  is  presented  in  the  GO  diagram  in  Figure  10  below. 
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Figure  10.  GO  Diagram  of  the  Standard  Model  with  Tasks  A,  B,  C,  D  and  E. 

The  key  differenees  between  this  model  and  that  of  the  standard  model  is  this 
model  adds  an  additional  task,  task  E  and  also  has  a  third  feedback  to  consider,  naturally, 
the  options  which  become  additionally  available  when  this  newest  task  is  added.  With 
these  changes,  once  again,  additional  operators  are  needed  as  well  as  the  requisite 
operator  types  changed  to  allow  for  a  representative  model  to  be  created.  Task  A  has  a 
total  of  four  paths,  this  additional  path  to  take  is  one  from  task  A  directly  to  task  E.  A 
choice  can  be  made  after  accomplishing  task  B  to  go  directly  to  task  D  or  E.  If  task  B 
fails,  there  are  now  three  options,  either  accomplish  task  A  and  go  to  task  C  or  D  and  now 
task  E.  East,  there  is  now  another  option  should  task  D  fail.  If  task  D  should  fail,  there  is 
now  an  option  to  return  to  task  A  and  the  go  directly  to  task  E.  At  this  point  in  this 
demonstration,  these  changes  to  system  paths  or  choices  are  to  be  expected. 

Note  the  type  5  operator  is  moved  again  in  this  model  prior  to  the  single  input 

needed  to  model  the  failure  of  task  D  and  the  choice  to  perform  task  A  and  then  go  to 

task  E.  An  additional  choice  is  made  for  the  type  4  operators  for  tasks  B  failing  and  task 

C  failing  is  made  to  satisfy  the  need  to  have  the  additional  task  choice  available  after  task 

B  and  C.  Once  again,  the  additions  and  uses  of  the  type  9  operators  in  this  model  are  the 

42 


same  as  how  the  type  9  operators  used  in  the  standard  and  simple  models.  As  expeeted, 
an  OR  gate  is  used  to  reeeive  all  possible  paths  whieh  ean  be  taken  prior  to  task  E  as  well 
as  the  type  1  operator  used  to  model  task  E. 

A  Monte  Carlo  simulation  was  ereated  with  Mierosoft  Exeel  TM  with  random 
numbers  generated  and  propagated  into  a  table.  The  Monte  Carlo  simulation  results  for 
the  various  signals  mateh  the  GO  results.  Both  the  eodes  for  the  Monte  Carlo  and  the  GO 
program  are  available  for  review  in  Appendix  B. 

F.  CHAPTER  SUMMARY 

The  feedbaek  loop  ean  be  a  eomplieated  element  to  integrate  into  a  GO  bloek 
diagram.  The  approaeh  for  simplifying  the  integration  is  to  analyze  how  many  feedbaeks 
are  required  and  to  seleet  the  appropriate  operator  types  to  fit  the  system.  When 
advaneing  from  a  simple  feedbaek  loop  with  one  feedbaek  element  and  one  path  after  the 
element  to  the  most  eomplex  feedbaek  loop  deseribed  in  this  study,  the  steps  required  to 
seleet  the  operator  type  beeome  elear.  One  feedbaek  loop  with  one  path  after  the 
feedbaek  element  requires  a  type  5  operator  with  a  type  9  operator.  One  feedbaek  loop 
with  two  or  more  paths  after  the  feedbaek  element  would  neeessitate  seleeting  a  type  4 
operator  and  for  eaeh  path  added  and  an  additional  type  9  operator  ineluded.  Eastly,  with 
two  or  more  feedbaek  loops  integrated  into  a  system,  the  engineer  must  determine  if  a 
type  5  operator  is  needed,  whieh  represents  a  single  path  after  the  feedbaek  element,  or  if 
type  4  operators  are  needed,  representing  more  than  one  path  after  the  feedbaek  element. 
The  remaining  aspeets  of  integrating  feedbaek  loops  involve  adding  the  additional  signals 
required  so  that  all  additional  paths  available  in  the  eireuit  are  represented  in  the  GO 
bloek  diagram. 
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V.  APPLICATION  OF  STUDY 


A,  INTRODUCTION 

With  the  ability  of  the  GO  program  to  perform  analyses  for  both  reliability 
engineering  and  system  safety,  there  are  benefits  and  effieieneies  that  may  be  leveraged 
within  systems  engineering.  System  safety  engineers  have  overlapping  interests  with 
engineering  diseiplines  aeross  those  within  systems  engineering.  Obviously  there  is  a 
link  between  the  diseiplines  of  system  safety  and  reliability.  In  addition,  diseiplines  of 
design  arehiteeture,  software  engineering,  mission  assuranee  and  speeialty  engineering  to 
name  a  few  would  reeeive  benefit  from  modeling  elements  of  their  diseiplines  with  the 
GO  program. 

To  best  illustrate  the  benefits  of  using  a  eommon  tool,  sueh  as  the  GO  program, 
for  multi-diseiplinary  work  within  systems  engineering,  a  survey  designed  by  Mr.  Tyrone 
Jaekson  was  sent  out  to  mission  assuranee  engineering  experts  in  the  field  of  defense 
systems  engineering,  manufaeturing  and  development.  The  survey  was  designed  to 
eolleet  the  opinions  of  the  mission  assuranee  experts  regarding  mission  assuranee 
defieieney  analysis  methodologies.  The  results  of  the  survey  were  then  eorrelated  to 
determine  areas  of  eommonality. 

There  are  three  tables  presented  in  this  study  whieh  referenee  information 
presented  as  part  of  the  survey.  The  first  table  is  a  list  of  defieieney  analysis 
methodologies  that  are  presented  in  Table  13  below.  This  list  is  ineluded  in  the  survey 
and  it  represents  the  set  of  defieieney  analysis  methodologies  eurrently  being  applied  by 
mission  assuranee  experts.  The  methodology  list  also  ineludes  an  opportunity  for  a  tool 
or  methodology  not  identified  within  the  survey  to  be  manually  written  in  and  identified 
by  the  survey  taker,  whieh  is  listed  in  the  survey  as  item  W.  The  seeond  table  eontains 
lists  of  produets  grouped  aeeording  to  unit-values,  from  Category  1  through  5,  that  are 
presented  in  Table  14.  These  lists  are  ineluded  in  the  survey  as  Figure  3,  and  they 
represent  produets  whieh  are  grouped  aeeording  to  the  relative  impaet  of  their  worst-ease 

failure,  in  terms  of  potential  human,  environmental,  and  finaneial  losses,  in  that  order. 
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For  example,  the  products  in  the  Category  5  list  represent  products  which  have  the 
highest  unit-values,  and  the  products  listed  in  the  Category  1  column  represent  systems 
which  have  the  lowest  unit-values.  The  third  and  final  table  contains  the  survey 
questions  that  are  presented  in  Table  15.  The  survey  questions  relate  the  preferred 
mission  assurance  approaches  among  mission  assurance  experts  who  took  the  survey, 
with  respect  to  their  selection  of  particular  deficiency  analysis  methodologies  for 
particular  unit-value  categories  of  products.  The  results  of  the  survey  correlate  the 
commonality  of  preferred  approaches  among  mission  assurance  experts,  as  demonstrated 
by  each  selecting  nearly  all  of  the  deficiency  analysis  methodologies  for  Category  5  unit- 
value  products. 


A.  Functional  Diagram  Modeling 

B.  System  Reliability  Modeling 

C.  Component  Reliability  Predictions 

D.  Product  Failure  Mode,  Effects  and  Criticality  Analysis 

E.  Sneak  Circuit  Analysis 

E.  Design  Concem/Rule  Analysis 

G.  Parts  Stress  Derating  Analysis 

H.  Worst  Case  Analysis 

I.  Human  Error  Predictions 

J.  Environmental  Event  Survivability  Predictions 

K.  Anomaly  Detection  and  Response/Eailure  Coverage  Analysis 
E.  Maintainability  Predictions 

M.  Operational  Dependability/Availability  Modeling 

N.  Hazard/Safety  Analysis 

O.  Software  Component  Reliability  Predictions 

P.  Process  Eailure  Mode,  Effects  and  Criticality  Analysis 

Q.  Event  Tree  Analysis 

R.  Eault  Tree  Analysis 

S.  Eishbone  Analysis 

T.  Similarity/ Allocations  Analysis 

U.  Parts  Engineering  Analysis 

V.  Stress  and  Damage  Simulation  Analysis 

W.  Other  Deficiency  Analysis  Methodology: _ 


Table  13.  Eist  of  Deficiency  Analysis  Methodologies  Used  in  Survey. 
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Unit-Value  Category  1 

•  Motorized/  manual  hand  tools 

•  Fire  arms 

•  Explosive  deviees 

•  Consumer  eleetronies 

•  Personal  eomputers 

•  Household  applianees 

•  Battery  operated  toys 

•  Infant/  ehildren  toys 

Unit- Value  Category  2 

•  Automobiles/  trueks/  motoreyeles 

•  Reereational  vehieles/  motor  homes 

•  Industrial  eleetronies 

•  Experimental/  kit  aireraft 

•  Computer  servers 

•  farm  equipment 

•  Medieal/  laboratory  equipment 

•  f  aetory  maehinery 

•  Test  equipment/  software 

•  Mobil  eonstruetion/  demolition/ 
mining  equipment 

•  Mobil  eommunieations  equipment 

Unit-Value  Category  3 

Unit- Value  Category  4 

•  Experimental  satellites 

•  Communieations  satellites 

•  Small  private  aireraft/helieopters 

•  fossil  fuel/hydro-eleetrie  power  plants 

•  Commereial  buses 

•  Water  filtration  plants 

•  Oil  tankers/  rigs 

•  Short-range  missiles/roekets 

•  Ereighters 

•  Commereial  passenger  aireraft/ 

•  Ground-mobile/  ground-fixed  military 

helieopters 

eleetronies 

•  Military  aireraft/  helieopters 

•  Ground-mobile/  ground-fixed 

•  Military  drones/  unmanned  vehieles 

eonventional  military  weapons 

•  Oeean  liners 

•  freight  trains 

•  Diesel-powered  naval  vessels 

•  Unmanned  terrestrial  exploration 

•  Passenger  trains 

vehieles 

•  Airborne  military  eleetronies 

•  Amusement  park  rides 

•  Extraterrestrial  exploration  vehieles 

•  Elevators/  esealators 

Unit-Value  Category  5 

•  Defense  satellites 

•  Eauneh  vehieles 

•  Eong-range  missiles 

•  Nuelear-powered  naval  vessels 

•  Nuelear  weapons 

•  Nuelear  power  plants 

•  Manned  spaeeeraft 

•  Spaee  stations 

•  Extraterrestrial  manned  habitats 

Table  14.  List  of  Unit- Value  Category  Definitions. 
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1.  Which  of  the  deficiency  analysis  methodologies  would  you  recommend  be  used  to 
assess  deficiencies  of  a  Capability  Level  1  product  in  Figure  3? 

Highlight  letters  which  correspond  to  methodologies  applicable  to  Capability  Level  1  products. 

[A]  [B]  [C]  [D]  [E]  [F]  [G]  [H]  [I]  [J]  [K]  [L]  [M]  [N]  [O]  [P]  [Q]  [R]  [S]  [T]  [U]  [V]  [W] 

2.  Which  of  the  deficiency  analysis  methodologies  would  you  recommend  be  used  to 
assess  deficiencies  of  a  Capability  Level  2  product  in  Figure  3? 

Highlight  letters  which  correspond  to  methodologies  applicable  to  Capability  Level  2  products. 

[A]  [B]  [C]  [D]  [E]  [F]  [G]  [H]  [I]  [J]  [K]  [L]  [M]  [N]  [O]  [P]  [Q]  [R]  [S]  [T]  [U]  [V]  [W] 

3.  Which  of  the  deficiency  analysis  methodologies  would  you  recommend  be  used  to 
assess  deficiencies  of  a  Capability  Level  3  product  in  Figure  3? 

Highlight  letters  which  correspond  to  methodologies  applicable  to  Capability  Level  3  products. 

[A]  [B]  [C]  [D]  [E]  [F]  [G]  [H]  [I]  [J]  [K]  [L]  [M]  [N]  [O]  [P]  [Q]  [R]  [S]  [T]  [U]  [V]  [W] 

4.  Which  of  the  deficiency  analysis  methodologies  would  you  recommend  be  used  to 
assess  deficiencies  of  a  Capability  Level  4  product  in  Figure  3? 

Highlight  letters  which  correspond  to  methodologies  applicable  to  Capability  Level  4  products. 

[A]  [B]  [C]  [D]  [E]  [F]  [G]  [H]  [I]  [J]  [K]  [L]  [M]  [N]  [O]  [P]  [Q]  [R]  [S]  [T]  [U]  [V]  [W] 

5.  Which  of  the  deficiency  analysis  methodologies  would  you  recommend  be  used  to 
assess  deficiencies  of  a  Capability  Level  5  product  in  Figure  3? 

Highlight  letters  which  correspond  to  methodologies  applicable  to  Capability  Level  5  products. 

[A]  [B]  [C]  [D]  [E]  [F]  [G]  [H]  [I]  [J]  [K]  [L]  [M]  [N]  [O]  [P]  [Q]  [R]  [S]  [T]  [U]  [V]  [W] 


Table  15.  List  of  Deficiency  Analysis  Methodologies  Survey  Questions. 


The  results  of  the  survey  revealed  there  are  extensive  overlapping  engineering 
design  areas,  requirements  and  analyses.  Figures  11,  12  and  13  are  examples  of  these 
overlapping  areas  with  the  figures  taken  directly  from  the  results  generated  by  the  author 
of  the  survey.  The  author  states,  “Without  detailed  planning,  this  overlap  may  result  in 
instances  of  duplication  in  effort  or  process  escapement  among  different  disciplines.” 
The  results  of  this  survey  directly  support  the  development  and  use  of  common  use  tools 
such  as  the  GO  program  for  inter-disciplinary  application  and  use  of  analyses 
methodologies. 
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Satellite 
Mission-Critical 
Functions: 

Payload 


SC  Elec' 
Pwr 


Satellite 
Safety-Critical 
Functions: 


/  Communication 

1  •  SC  Propulsion  ^ 

•  SC  Communication  \ 

•  Payload  Telemetry 

•  SC  Guidance 

•  SC  Health  &  Status 

•  Payload  Computer 

•  SC  Thermal  CntI 

\  •  Payload  Anomaly 

\  Detection  &  Response 

\  •  SC  Computer  / 

/ 

\  •  Payload  Mission 
\  Equipment 

\  .  SC  ADR  / 

Figure  1 1 .  Example  Overlap  of  Safety-Critical  and  Mission-Critical  Design  Attributes. 


Reliability  & 
Maintainability 
Requirements: 


»  System  Reliability 

Critical  Item  Control 
(Mission-Critical) 


System  Safety 
Requirements: 


•  Single  Fault 
Tolerance 
(Mission-Critical) 

•  Critical  Item 
Control 


Mishap  Probability 

Dual  Fault  Tolerance 
(Safety-Critical ) 

Environmental  & 
Occupational  Flealth 
Requirements 


Figure  12. 


Example  Overlap  of  System  Safety  and  Reliability  /  Maintainability 

Requirements. 
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Reliability  & 
Maintainability 
Analyses: 

Parts  Stress 

Derating  Analysis  /  •  Functional 

System  Reliability 
Modeling 


Component  Reliability 
Predictions 

•  Maintainability 
Predictions 

Operational 
Dependability 
Modeling 


Figure  13.  Example  Overlap  of  System  Safety  and  Reliability  /  Maintainability  Analyses. 

B.  RECOMMENDATIONS 

A  better  understanding  of  the  benefits  of  using  a  systematic,  structured,  updateable 
and  repeatable  method  of  analyses  provides  a  more  complete  assessment  of  the  performance 
of  a  system  as  a  whole  as  well  as  offer  opportunities  for  identifying  previously  unknown 
risks.  Beginning  with  architectural  considerations  and  continuing  through  the  final 
integration  of  system  elements,  there  are  benefits  to  having  a  common  tool  to  be  used  across 
all  disciplines  for  design  selections  and  risk,  reliability  and  safety  analyses. 

Eliminating  or  reducing  the  amount  of  rework  from  similar  disciplines  with  differing 
requirements  is  an  immediate  application  which  could  lead  to  reducing  cost  and  schedule  for 
complex  and  often  cost  intensive  systems.  Taking  advantage  of  the  inventory  of  computer 
aided  tools  currently  available  and  finding  and  exploiting  the  synergies  of  easy  to  use  tools 
will  also  immediately  reduce  the  logistical  footprint  of  multiple  analyses  techniques.  With 
the  ability  of  the  GO  program  to  perform  analyses  for  both  reliability  engineering  and  system 
safety,  these  benefits  and  efficiencies  may  be  leveraged  within  systems  engineering  efforts. 
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VI.  CONCLUSIONS 


A,  KEY  POINTS  AND  RECOMMENDATIONS 

With  the  demonstrated  ability  of  the  GO  program  to  eorreetly  model  feedback 
loops,  it  clears  a  path  for  the  Department  of  Defense  to  investigate  the  benefits  of 
adopting  a  standardized  approach  for  the  analyses  of  complex  systems.  The  use  of 
computerized  tools  aids  greatly  in  assessing  complex  systems  and  the  ability  of  the 
systems  to  meet  requirements.  In  the  introduction  chapter  of  this  study,  ten  points  were 
made  regarding  the  benefits  of  using  the  GO  program  as  a  common  analyses  tool  across 
multiple  disciplines.  The  list  of  benefits  is  repeated  below. 

1 .  There  are  no  commonly  known  commercial  reliability  modeling  tools  available 
that  are  driven  by  a  functional  model.  Performing  reliability  modeling  using 
mathematical  models  introduces  errors  when  function-level  probabilities  of 
occurrence  are  involved. 

2.  There  are  no  commonly  known  commercial  FMECA  (Failure  Modes  and 
Effects  Criticality  Analysis)  tools  available  that  are  driven  by  a  functional  model. 
Performing  EMECA  manually  using  worksheets  is  likely  to  introduce  errors  when 
complex  systems  are  involved. 

3.  There  are  no  commonly  known  commercial  event  tree  analysis  tools  available 
that  are  driven  by  a  functional  model.  Performing  event  tree  analysis  manually 
using  worksheets  introduces  errors  when  latent  operating  modes  are  involved. 

4.  There  are  no  commonly  known  commercial  fault  tree  analysis  tools  available 
that  are  driven  by  a  functional  model.  Performing  fault  tree  analysis  manually 
using  logic  symbols  introduce  errors  when  complex  systems  are  involved. 

5.  There  are  no  commonly  known  commercial  engineering  tools  available  that 
integrate  reliability  modeling,  EMECA,  event  sequence  analysis,  and  fault  tree 
analysis.  Performing  these  analyses  separately  using  different  methods  is  labor- 
intensive  and  introduces  errors  when  trying  to  integrate  the  results. 

6.  There  is  no  commonly  known  commercial  suite  of  integrated  safety/reliability 
tools  available.  One  of  the  benefits  in  a  future  study  is  the  research  involved  in 
defining  an  "enhanced  GO"  tool  which  allows  integrating  safety  and  reliability 
analyses  via  output  which  includes  function-level  failure  cut-sets  and  function- 
level  probabilities  of  success. 
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7.  There  are  no  eommonly  known  eommereial  reliability  modeling  tools  available 
that  are  driven  by  a  funetional  model  whieh  is  eompliant  with  an  industry 
approved  standard.  The  AIAA  S-102  Mission  Assuranee  Standards  Working 
Group  is  interested  in  eoordinating  the  further  development  of  an  "enhaneed  GO" 
to  ereate  an  Open  Souree  tool  whieh  is  driven  by  a  funetional  model  that  is 
eompliant  with  the  S-102  Funetional  Diagram  Modeling  standard. 

8.  There  are  no  eommonly  known  eommereial  reliability  modeling  tools  available 
whieh  allow  feedbaek  to  be  ineluded  in  the  model.  One  of  the  topies  in  this  study 
is  the  researeh  involved  in  defining  an  "enhaneed  GO"  whieh  allows  feedbaek  to 
be  ineluded  in  the  reliability  model.  GO  automatieally  generates  the  reliability 
model  from  the  funetional  model. 

9.  There  are  no  eommonly  known  eommereial  reliability  modeling  tools  available 
whieh  provide  output  in  a  format  whieh  is  eompliant  with  an  industry  approved 
standard.  The  AIAA  S-102  Mission  Assuranee  Standards  Working  Group  is 
interested  in  eoordinating  the  further  development  of  an  "enhaneed  GO"  to  ereate 
an  Open  Souree  tool  whieh  provides  output  whieh  is  eompliant  with  the  XML 
data  element  deseriptions  defined  in  the  S-102  standards. 

10.  In  the  past  25  years,  very  few  eommereial  reliability  analysis  tools  were 
developed  that  are  driven  by  funetional  models  and  whieh  ean  perform  multiple 
analyses.  One  of  these  tools  is  ealled  MultiLinx,  whieh  was  used  in  the  NASA 
Crew  Return  Vehiele  (CRV)  program  between  1998  and  2003.  This  tool  was  not 
marketed  in  the  publie  domain  after  the  CRV  program  ended.  The  other  tool  is 
ealled  eXpress,  and  it  is  eurrently  used  by  many  eompanies  to  analyze  the 
testability  of  a  design.  The  eXpress  tool  is  not  intended  to  be  used  in  safety 
design  or  reliability  design  assessments.  An  "enhaneed  GO"  eould  beeome  the 
affordable  Open  Souree  alternative  whieh  supports  both  safety  design  and 
reliability  design  assessments. 

Eaeh  of  the  above  numbered  items  may  be  integrated  into  a  government  approved 
approaeh  for  use  throughout  the  entire  lifeeyele  of  a  system.  There  are  opportunities  to 
improve  the  way  the  government  and  the  eontraetor  use  the  best  praetiees  available  for 
aequiring  systems  of  ever  inereasing  eost  and  eomplexity.  Common  tools  with 
universally  available,  doeumented,  and  understood  methodologies  for  their  use  will 
improve  the  government’s  oversight  of  defense  aequisition  systems  and  inerease  the 
eontraetor’ s  awareness  of  the  impaets  of  design  deeisions  and  ehanges  throughout  the  life 
eyele  systems  engineering  proeess. 
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B, 


AREAS  TO  CONDUCT  FURTHER  RESEARCH 


The  GO  program  is  currently  designed  to  read  in  data  files,  perform  analyses  and 
write  data  files  presented  in  a  table  format  for  review.  Each  of  the  files  read  are  created 
by  the  engineers  who  have  a  high  familiarity  with  the  system  being  modeled.  This 
technology  has  an  opportunity  to  be  updated  with  the  power  and  complexity  of  the 
computers  of  today  and  the  improved  ease  of  use  with  graphical  user  interfaces.  One 
initial  area  in  which  the  ease  of  the  use  of  this  program  can  be  greatly  improved  would  be 
for  a  computer  or  software  engineer  to  design  a  graphical  user  interface.  Another  benefit 
which  may  be  gained  is  in  possibly  having  the  GO  code  updated  to  operate  in  code  which 
is  more  advanced  than  FORTRAN,  potentially  allowing  for  greater  application  of  the 
code  or  for  obtaining  intermediate  levels  of  results  of  analyses.  The  interested  reader  will 
find  all  of  the  input  files  used  to  create  the  single,  standard  and  complex  models  in 
Appendix  C. 
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APPENDIX  A.  MONTE  CARLO  SIMULATION  AND  GO  CODES 


GO  Code 

1  4  23  0  10  0.8  10  1  0.1  10  10  0.1  $  FIRST  LVL  A 

Explanation 

Value  of  0  with  probability  of  0.8  is  a  given  property  for  the 
probability  of  this  value  on  signal  1 

Value  of  10  with  a  combined  probability  of  0.2  is  a  given  property 
for  the  probability  of  this  value  on  signal  1 

Excel  Code 

=IF(rand_num<sig_1_percent,0,10) 

Signal  1 

Explanation 

If  the  random  number  is  less  than  the  assigned  signal  1  percent 
(0.80),  the  value  is  0  else  the  value  is  10. 

Math: 

N/A  based  on  random  number  generator 

Note: 

There  is  an  value  of  10  on  signal  1  and  10  on  signal  2  10%  of  the 
time.  This  is  done  to  allow  for  a  condition  for  the  value  4,  which 
originates  at  signal  7  to  be  output  at  the  OR  gate  The  logic  of  the 
OR  gate  is  that  the  signal  with  the  lowest  value  will  be  passed  at 
the  gate 

Table  16.  GOl  and  Excel  Code  Signal  1  for  Single  Model. 


GO  Code 

1  4  2  3  0  100.8  10  1  0.1  10  10  0.1  $  FIRST  LVL  A 

Explanation 

Value  of  10  with  probability  of  0.1  is  a  given  property  for  the 
probability  of  this  value  on  signal  2. 

Signal  2 

Value  of  0  with  a  combined  probability  of  0.9  is  a  given  property 
for  the  probability  of  this  value  on  signal  2 

Excel  Code 

=IF(AND(rand_num>=0.8,rand_num<0.9),1,10) 

Explanation 

If  the  random  number  is  less  than  the  assigned  signal  2  percent 
(net  0.10),  the  value  is  0  else  the  value  is  10. 

Math: 

N/A  based  on  random  number  generator 

Note: 

No  notes  for  this  signal 

Table  17.  GOl  and  Excel  Code  Signal  2  for  Single  Model. 


55 


Signal  5 

GO  Code 

5  1  0.8  0.2  $  SECOND  LVLC 

Explanation 

The  type  1  operator  passes  signals  based  on  a  predetermined 
success/failure  rate 

Excel  Code 

=IF(rand_num5<0.8,signal_1,10) 

Explanation 

If  the  random  number  is  less  than  the  assigned  signal  5  percent 
(0.80),  the  value  on  signal  1  is  passed  else  the  output  value  is  10. 
Based  on  the  random  number  generator,  any  random  numbers 
less  than  signal  Ts  assigned  percentage  (0.80)  will  be  passed. 

Math: 

The  multiplication  is  0.80  times  the  probabilities  of  the  values 
found  on  signal  10 

Value 

Signal  1 

Multiply 

Signal  5 

0 

0.80000007 

Multiplied  by  0.80 

0.64000006 

1 

0.00000000 

Multiplied  by  0.80 

0.00000000 

3 

0.00000000 

Multiplied  by  0.80 

0.00000000 

4 

0.00000000 

Multiplied  by  0.80 

0.00000000 

10 

0.20000002 

0.36000001 

Note: 

The  failure  value  is  represented  by  the  addition  of  0.80  *  0.2  = 

0.16  plus  the  0.20  failure  rate  of  the  type  1  operator,  totaling  0.36 
An  alternative  way  to  get  this  number  is  to  add  all  of  the  values  for 
the  signals  0-4  and  subtract  from  1  which  will  also  yield  the 
overall  failure  rate. 

Table  18.  GOl  and  Excel  Code  Signal  5  for  Single  Model. 


GO  Code 

8  153  10  0  00  1  $  VALUE  CHANGER 

Explanation 

Value  of  3  with  probability  of  0.8  is  a  given  property  due  to  the 
inputs  going  to  the  type  15  operator. 

Value  of  10  with  probability  of  0.2  is  a  given  property  due  to  the 
inputs  going  to  the  type  15  operator. 

Excel  Code 

=IF(signal_5=0,3,10) 

Signal  6 

Explanation 

If  Signal  5  =0,  the  output  is  three  else  the  output  is  10. 

Math: 

N/A  based  on  inputs  received  which  are  determined  by  random 
numbers  generated  at  Signal  1  and  Signal  5 

Note: 

Note:  15-8  has  no  probability  associated  with  it.  It  simply  has  an 
output  based  on  the  input  received.  The  code  for  this  type 
operator  is  for  any  input  of  0,  the  output  is  3,  otherwise  the  output 
is  10. 

Table  19.  GOl  and  Excel  Code  Signal  6  for  Single  Model. 
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GO  Code 

2  5  24  0.8  10  0.2  $  B  FAIL  INPUT 

Explanation 

Value  of  4  with  probability  of  0.8  is  a  given  property  due  to  the 
inputs  going  to  the  type  5  operator 

Value  of  10  with  probability  of  0.2  is  a  given  property  due  to  the 
inputs  going  to  the  type  5  operator 

Signal  7 

Excel  Code 

=IF(rand_num2<sig_7_percent,4,10) 

Explanation 

Similar  to  the  type  four  operator  on  signals  1  and  2,  if  the  random 
number  (this  time  random  number  2)  is  less  than  the  assigned 
signal  7  percent  (0.80),  the  value  is  4  else  the  value  is  10. 

Math: 

N/A  based  on  random  number  generator 

Note: 

No  notes  for  this  signal 

Table  20.  GOl  and  Excel  Code  Signal  7  for  Single  Model. 


GO  Code 

6  9  1-6-6$  TYPE  9  MODEL1 

Explanation 

Value  of  4  is  output  when  the  input  on  signal  6  is  1 0  and  the  input 
on  signal  7  is  4,  otherwise  the  output  is  10 

Excel  Code 

=IF(AND(signal_7=4,signal_6=10),4,10) 

Signal  9 

Explanation 

Excel  populates  this  data  based  on  the  values  available  from  the 
previous  signals  generated  from  the  random  numbers  This  will  not 
produce  an  exact  probability  value,  but  on  average,  due  to  the 
nature  of  probability  the  average  result  will  approximately  equal 
the  probability  value. 

Math: 

Based  on  logic  assigned  to  type  9  operator 

Note: 

No  notes  for  this  signal 

Table  21.  GOl  and  Excel  Code  Signal  9  for  Single  Model. 
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GO  Code 

No  probability  data  for  a  type  2  operator  which  is  an  or  gate. 

The  or  gate  will  take  the  lowest  value  from  the  signals  present 

Explanation 

This  or  gate  receives  signals  from  2,  6  and  9  to  pass  on  as  signal 
10. 

Excel  Code 

=MIN(signal_2,signal_6,signal_9) 

Explanation 

Excel  function  MIN  does  the  same  operation  as  described  for  the 
type  2  operator  for  the  GO  program 

Signal  2  probability  value  is  directly  associated  with  percentage 
value  assigned  on  line  2  of  the  code,  with  line  2  being  0.10  for 
value  1 ,  the  or  gate  signal  is  0. 1 

Signal 

10 

Signal  6  probability  value  is  directly  associated  with  percentage 
value  assigned  on  line  1  of  the  code,  with  line  1  being  0.80  for 
value  0,  the  or  gate  signal  is  0.80 

Math: 

Signal  9  probability  value  is  directly  associated  with  percentage 
value  assigned  on  line  3  of  the  code,  with  line  3  being  0.10  for 
value  10  to  be  present  at  the  same  time  on  signals  1  and  2, 
multiplied  by  the  percentage  assigned  to  the  signal  7  operator, 
which  is  0.80  The  probability  for  signal  9  to  be  passed  at  the  or 
gate  is  0.80  *  0.10  =  0.08 

The  last  value  passed  at  the  or  gate  is  1 0  which  only  happens  in 
this  case  when  signals  1  and  2  are  10  and  when  signal  7  results 
in  a  10  (in  this  case  20  percent) 

0.20  times  0.10 

(signal  7  failure  times  signal  1  and  2  failure)  =  0.02 

Note: 

No  notes  for  this  signal 

Table  22.  GOl  and  Excel  Code  Signal  10  for  Single  Model. 
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GO  Code 

5  1  0.8  0.2  $  SECOND  LVLC 

Explanation 

The  type  1  operator  passes  signals  based  on  a  predetermined 
success/failure  rate 

Excel  Code 

=IF(rand_num3<0.8,MIN(signal_2,signal_6,signal_9),10) 

Explanation 

If  the  random  number  is  less  than  the  assigned  signal  11  percent 
(0.80),  the  value  on  signal  10  is  passed  else  the  output  value  is 

10.  Based  on  the  random  number  generator,  any  random 
numbers  less  than  signal  1  Ts  assigned  percentage  (0.80)  will  be 
passed. 

Signal 

The  multiplication  is  0.80  *  the  probabilities  of  the  values  found 
on  signal  10 

11 

Value 

Signal  10 

Multiply 

Signal  11 

Math: 

0 

0.00000000 

Multiplied  by  0.80 

0.00000000 

1 

0.10000001 

Multiplied  by  0.80 

0.08000001 

3 

0.64000005 

Multiplied  by  0.80 

0.51200002 

4 

0.20800000 

Multiplied  by  0.80 

0.16640002 

10 

0.05200000 

0.24160000 

Note: 

The  failure  value  is  represented  by  the  addition  of  0.80  *  0.052  = 
0.0416  plus  the  0.20  failure  rate  of  the  type  1  operator,  totaling 
0.2416  An  alternative  way  to  get  this  number  is  to  add  all  of  the 
values  for  the  signals  0-4  and  subtract  from  1  which  will  also  yield 
the  overall  failure  rate. 

Table  23.  GOl  and  Excel  Code  Signal  1 1  for  Single  Model. 
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APPENDIX  B.  MONTE  CARLO  SIMULATIONS 


RV1 

RV2 

RV3 

RV4 

Signal  1 

0.72 

0.56 

0.71 

0.08 

Description 

A  to  B 
signal  1, 
state  0/10 

Likelihood 

80% 

Random 

Variablet 

Random 

Variable2 

Random 

Variable3 

Random 

Variable4 

RV  1 

=IF(rand num<sig 1 percent,0,10) 

Exp 

# 

0.72 

0.56 

0.71 

0.08 

0 

1 

0.05 

0.54 

0.99 

0.23 

0 

2 

0.52 

0.60 

0.99 

0.02 

0 

3 

0.29 

0.07 

0.03 

0.52 

0 

4 

0.20 

0.40 

0.30 

0.83 

0 

5 

0.74 

0.39 

0.92 

0.88 

0 

Table  24.  Single  Model  Simulation  Deseription  for  Signal  1. 


Signal  2 

Signal  5 

Signal  6 

AtoC 
signal  2, 
state  1/10 

BtoC 
signal  2, 
state  1/10 

B  to  C  signal  6, 
state  3/1 0 

10% 

80% 

N/A 

RV  1 

RV2 

N/A 

=IF(AND(rand  num>=0.8,rand  num<0.9), 

=IF(rand  num2<0. 8, signal  1, 

=IF(signal  5=0,3, 

1,10) 

10) 

10) 

10 

0 

3 

10 

0 

3 

10 

0 

3 

10 

0 

3 

10 

0 

3 

10 

0 

3 

Table  25.  Single  Model  Simulation  Deseription  for  Signals  2,  5  and  6. 
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Signal  7 

Signal  9 

Task  B  fails;  A  to  C 

Task  B  Fails;  A  to  C 

signal  7, 

signal  9, 

state  4/10 

state  4/10 

80% 

N/A 

RV3 

N/A 

=IF(rand num3<sig 7 percent,4,10) 

=IF(AND(slgnal 7=4,signal 6=10),4,10) 

4 

10 

10 

10 

10 

10 

4 

10 

4 

10 

10 

10 

Table  26.  Single  Model  Simulation  Description  for  Signals  7  and  9. 


Signal  10 

Signal  11 

Or  Gate  to  Task  C 

Task  C 

signal  10 

signal  11, 

state  1/3/4/10 

state  1/3/4/10 

N/A 

N/A 

N/A 

RV4 

=MIN(slgnal 2,slgnal 6,slgnal 9) 

=IF(rand num4<0.8,MIN(slgnal 2,slgnal 6,signal 9),10) 

3 

3 

3 

3 

3 

3 

3 

3 

3 

10 

3 

10 

Table  27.  Single  Model  Simulation  Description  for  Signals  10  and  11. 
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RV1 

RV2 

RV3 

RV4 

RV5 

Signal  1 

0.29 

0.27 

0.76 

0.04 

0.99 

Description 

A  to  B 
signal  1, 
state  0/10 

Likelihood 

80% 

Random 

Variable 

1 

Random 

Variable 

2 

Random 

Variable 

3 

Random 

Variable 

4 

Random 

Variable5 

RV  1 

=IF(rand_num<sig_ 

1  percent, 0,10) 

Exp 

# 

0.29 

0.27 

0.76 

0.04 

0.99 

0 

1 

0.17 

0.60 

0.86 

0.05 

0.02 

0 

2 

0.84 

0.64 

0.35 

0.32 

0.28 

10 

3 

0.64 

0.74 

0.11 

0.96 

0.22 

0 

4 

0.96 

0.62 

0.07 

0.23 

0.99 

10 

5 

0.38 

0.12 

0.30 

0.90 

0.91 

0 

Table  28.  Standard  Model  Simulation  Deseription  for  Signal  1. 


Signal  2 

Signal  3 

Signal  4 

Signal  5 

AtoC 
signal  2, 
state  1/10 

A  to  D 
signal  3, 
state  2/10 

B  to  D 
signal  4, 
state  0/1 0 

BtoC 
signal  5, 
state  0/10 

10% 

10% 

60% 

10% 

RV  1 

RV  1 

RV  1 

RV  1 

=IF(AND(rand_num> 
=0.8, rand  num<0.9), 
1,10) 

=IF(rand  num>0.9,2, 
10) 

=IF(AND(rand_num< 

(sig_4_percent*sig_1 

_percent)),0,10) 

=IF(AND(rand_num< 
((sig_4_percent*sig_ 
1_percent)+(sig_5_p 
ercent*sig_1_percent 
)),rand_num>=(sig_4 
percent*sig  1  perc 
ent)),0,10) 

10 

10 

0 

10 

10 

10 

0 

10 

1 

10 

10 

10 

10 

10 

10 

10 

10 

2 

10 

10 

10 

10 

0 

10 

Table  29.  Standard  Model  Simulation  Deseription  for  Signals  2,  3,  4  and  5. 
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Signal  6 

Signal  7 

Signal  8 

Signal  9 

B  to  c 
signal  6, 
state  3/1 0 

Task  B  fails;  A  to  C 
signal  7, 
state  4/1 0 

Task  B  fails;  A  to  D 
signal  8, 
state  5/10 

Task  B  Fails;  A  to  C 
signal  9, 
state  4/10 

N/A 

80% 

20% 

N/A 

N/A 

RV2 

RV2 

RV  1 

=IF{signal_5=0,3,10) 

=IF(rand_num2<sig_ 

7  percent, 4, 10) 

=IF(rand_num2>=si 
g  7  percent, 5, 10) 

=IF(AND(signal  6=1 0,s 
ignal  7=4),4,10) 

10 

4 

10 

4 

10 

4 

10 

4 

10 

4 

10 

4 

10 

4 

10 

4 

10 

4 

10 

4 

10 

4 

10 

4 

Table  30.  Standard  Model  Simulation  Deseription  for  Signals  6,  7,  8  and  9. 


Signal  10 

Signal  11 

Signal  12 

Signal  13 

Or  Gate  to  Task  C 
signal  10 
state  1/3/4/10 

Task  C 
signal  11, 
state  1/3/4/10 

Task  B  fails;  A  to  D 
signal  12, 
state  5/10 

Task  C  fails;  A  to  D 
signal  13, 
state  6/10 

N/A 

80% 

N/A 

N/A 

N/A 

RV3 

N/A 

RV4 

=MIN(slgnal_2,signal_ 

6,slgnal_9) 

= 1 F  (AN  D(ra  nd_n  u  m3< 
Q12),MIN(slgnal_2,sign 
al  6, signal  9), 10) 

=IF(AND(signal  8= 
5,signal  4=10), 5,10 
) 

=IF(rand  num4<0.8 
,6,10) 

4 

4 

10 

6 

4 

10 

10 

6 

1 

1 

10 

6 

4 

4 

10 

10 

4 

4 

10 

6 

4 

4 

10 

10 

Table  31.  Standard  Model  Simulation  Deseription  for  Signals  10,  11,  12  and  13. 
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Signal  14 

Signal  15 

Signal  16 

Task  C  fails;  A  to  D 
signal  14, 
state  6/1 0 

Or  Gate  to  Task  D 
signal  15, 

state  0/1/3/4/5/6/10 

Task  D 
signal  16, 

state  0/1/2/3/4/5/6/10 

N/A 

N/A 

80% 

N/A 

N/A 

RV5 

=IF(AND(slgnal  13=6, si 
gnal_11=10),6,10) 

=MIN(slgnal_3,signal_4,signa 
l_1 1,signal_12,signal_14) 

=IF(rand_num5<0.8,MIN(slgnal 
_3,signal_4,slgnal_1 1  ,slgnal_12 
, signal  14), 10) 

10 

0 

10 

6 

0 

0 

10 

1 

1 

10 

4 

4 

10 

2 

10 

10 

0 

10 

Table  32.  Standard  Model  Simulation  Description  for  Signals  14,  15  and  16. 


RV1 

RV2 

RV3 

RV4 

RV5 

RV6 

RV7 

0.72 

0.21 

0.99 

0.43 

0.00 

0.10 

0.91 

Description 

Likelihood 

Random 

Variable 

1 

Random 

Variable 

2 

Random 

Variable 

3 

Random 

Variable 

4 

Random 

Variable 

5 

Random 

Variable 

6 

Random 

Variable7 

Exp 

# 

0.33 

0.52 

0.36 

0.99 

0.69 

0.70 

0.51 

1 

0.06 

0.58 

0.08 

0.92 

0.48 

0.13 

0.73 

2 

0.86 

0.05 

0.32 

0.20 

0.36 

0.43 

0.35 

3 

0.92 

0.01 

0.59 

0.11 

0.46 

0.47 

0.44 

4 

0.17 

0.81 

0.33 

0.02 

0.37 

0.95 

0.76 

5 

0.76 

0.54 

0.92 

0.79 

0.99 

0.26 

0.79 

Table  33.  Complex  Model  Simulation  Description  for  Random  Variables. 
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Signal  1 

Signal  2 

Signal  3 

Signal  17 

A  to  B 
signal  1, 
state  0/20 

AtoC 
signal  2, 
state  1/20 

A  to  D 
signal  3, 
state  2/20 

A  to  D 
signal  17, 
state  7/20 

70% 

10% 

10% 

10% 

RV  1 

RV  1 

RV  1 

RV  1 

=IF(rand_num<sig_ 

1_percent,0,20) 

=IF(AND(rand_num 
>=0.7, rand  num<0. 
8), 1,20) 

=IF(AND(rand_num 
>=0.8, rand  num<0. 
9),2,20) 

=IF(rand  num>0.9, 
7,20) 

0 

20 

20 

20 

0 

20 

20 

20 

20 

20 

2 

20 

20 

20 

20 

7 

0 

20 

20 

20 

20 

1 

20 

20 

Table  34.  Complex  Model  Simulation  Deseription  for  Signals  1,  2,  3  and  17. 


Signal  4 

Signal  5 

Signal  18 

Signal  6 

B  to  D 
signal  4, 
state  0/20 

BtoC 
signal  5, 
state  0/20 

BtoE 
signal  18, 
state  0/20 

BtoC 
signal  6, 
state  3/20 

50% 

10% 

10% 

N/A 

RV  1 

RV  1 

RV  1 

N/A 

=IF(AND(rand_num 

<{sig_4_percent*sig 

_1_percent)),0,20) 

=IF(AND(rand_num 

<{sig_4_percent*sig 

_1_percent+sig_5_p 

ercent*sig_1_percen 

t),rand_num>=((sig_ 

4_percent*sig_1_per 

cent+sig_5_percent* 

sig_1_percent)- 

{sig_5_percent*sig_ 

1  percent))), 0,20) 

=IF(AND(rand_num 
<{sig_4_percent*sig 
_1_percent+sig_5_p 
ercent*sig_1_perce 
nt+sig_1 8_percent* 
sig_1_percent),rand 
_num>=(sig_4_perc 
ent*sig_1  _percent+ 
sig_5_percent*sig_1 
percent)), 0,20) 

=IF{signal  5=0,3,20 
) 

0 

20 

20 

20 

0 

20 

20 

20 

20 

20 

20 

20 

20 

20 

20 

20 

0 

20 

20 

20 

20 

20 

20 

20 

Table  35.  Complex  Model  Simulation  Deseription  for  Signals  4,  5,  6  and  18. 
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Signal  7 

Signal  8 

Signal  19 

Signal  9 

Task  B  fails;  A  to  C 
signal  7, 
state  4/20 

Task  B  fails;  A  to  D 
signal  8, 
state  5/20 

Task  B  Fails;  A  to  E 
signal  9, 
state  8/20 

Task  B  Fails;  A  to  C 
signal  9, 
state  4/20 

80% 

10% 

10% 

N/A 

RV2 

RV2 

RV2 

N/A 

=IF(rand_num2<sig 

_7_percent,4,20) 

=IF(AND(rand_num 
2>=sig_7_percent,r 
and_num2<(slg_7_ 
percent+sig  8  perc 
ent)),5,20) 

=IF(AND(rand_num2> 
=(sig_7_percent+sig_8 
_percent),rand_num2< 
{sig_7_percent+slg_8_ 
percent+sig  19  perce 
nt)),8,20) 

=IF{AND(slgnal_6=20, 

slgnal_7=4),4,20) 

4 

20 

20 

4 

4 

20 

20 

4 

4 

20 

20 

4 

4 

20 

20 

4 

20 

5 

20 

20 

4 

20 

20 

4 

Table  36.  Complex  Model  Simulation  Deseription  for  Signals  7,  8,  9  and  19. 


Signal  10 

Signal  11 

Signal  21 

Signal  12 

Or  Gate  to  Task  C 
signal  20, 
state  1/3/4/20 

Task  C 
signal  11, 
state  1/3/4/20 

Task  C 
signal  21, 
state  1/3/4/20 

Task  B  fails;  A  to  D 
signal  12, 
state  5/20 

N/A 

60% 

10% 

N/A 

N/A 

RV3 

RV3 

N/A 

=MIN(slgnal_2,signal_ 

6,signal_9) 

=IF(AND{rand_num3<V 

1 6), MIN(signal_2, signal 
_6,slgnal_9),20) 

=IF(rand_num3>(1- 
sig_21_percent),MIN(sl 
gnal  2, signal  6, signal 
9),20) 

=IF{AND(signal  8= 
5,slgnal  4=20),5,20 
) 

4 

4 

20 

20 

4 

4 

20 

20 

4 

4 

20 

20 

4 

4 

20 

20 

20 

20 

20 

20 

1 

20 

1 

20 

Table  37.  Complex  Model  Simulation  Description  for  Signals  10,  11,  12  and  21. 
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Signal  20 

Signal  13 

Signal  14 

Signal  22 

Task  B  fails;  A  to  E 
signal  20, 
state  9/21 

Task  C  fails;  A  to  D 
signal  13, 
state  6/20 

Task  C  fails;  A  to  D 
signal  14, 
state  9/20 

Task  C  fails;  A  to  E 
signal  22, 
state  9/20 

N/A 

80% 

N/A 

20% 

N/A 

RV4 

N/A 

RV4 

=IF(AND(signal_19 
=8, signal  18=20), 8, 
20) 

=IF(rand  num4<0.8 
,6,20) 

=IF(AND(slgnal  13=6,si 
gnal_1 1=20), 6,20) 

=IF(rand_num4>slg_ 

13_percent,9,20) 

20 

20 

20 

9 

20 

20 

20 

9 

20 

6 

20 

20 

20 

6 

20 

20 

20 

6 

6 

20 

20 

6 

6 

20 

Table  38.  Complex  Model  Simulation  Deseription  for  Signals  13,  14,  20  and  22. 


Signal  23 

Signal  15 

Signal  16 

Signal  24 

Task  C  fails;  A  to 

E 

signal  23, 
state  9/20 

Or  Gate  to  Task  D 
signal  15 

state  0/1/2/3/4/5/6/20 

Task  D 
signal  16, 

state  0/1/2/3/4/5/6/20 

Task  D  fails;  A  to 

E 

signal  24, 
state  10/20 

N/A 

N/A 

80% 

80% 

N/A 

N/A 

RV5 

RV6 

=IF(AND(slgnal_ 
22=9, signal  21  = 
20),9,20) 

=MIN(slgnal_3,signal_4,si 
gnal  11, signal  12, signal 
14) 

=IF(rand_num5<0.8,MIN( 
signal_3,slgnal_4,signal_ 
11, signal  12, signal  14), 2 
0) 

=IF(rand  num6< 
AF16, 10,20) 

9 

0 

0 

10 

9 

0 

0 

10 

20 

2 

2 

10 

20 

4 

4 

10 

20 

0 

0 

20 

20 

6 

20 

10 

Table  39.  Complex  Model  Simulation  Deseription  for  Signals  15,  16,  23  and  24. 
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Signal  25 

Signal  26 

Signal  27 

Task  C  fails;  A  to  E 
signal  25, 
state  1 0/20 

Or  Gate  to  Task  E 
signal  26 
state  0-10/20 

TaskE 
signal  27, 
state  0-10/20 

N/A 

N/A 

80% 

N/A 

N/A 

RV7 

=IF(AND(signal  24=10, 
signal_16=20), 10,20) 

=MIN(signal_16,signal_17,slg 
nal_1 8,signal_20,signal_21  ,si 
gnal_23,signal_25) 

=IF(rand_num7<AI16,MIN( 
signal_16,signal_17,signal 
_1 8,signal_20,signal_21  ,si 
gnal  23, signal  25), 20) 

20 

0 

0 

20 

0 

0 

20 

2 

2 

20 

4 

4 

20 

0 

0 

10 

1 

1 

Table  40.  Complex  Model  Simulation  Description  for  Signals  25,  26  and  27. 
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APPENDIX  C.  GO  PROGRAM  CODE 


G01  DATA  FOR  SINGLE  FEEDBACK  LOOP 
. 10/ 

4  1  2  1  2  $  FIRSTLVL  A 

1  5  1  5  $  SECOND  LVL  B 
15  8  5  6  $  VALUE  CHANGER 

5  2  7  $  SECOND  LVL  B 

9  6  6  7  9  $  TYPE  9  MODEL1 
203269  10  $  OR  GATE 
1  5  10  11  $  THIRD  LVLC 
0  11$  FINAL  SIGNALS 
EOR 


Table  41.  GOl  Data  For  Single  Feedback  Loop. 

G02  DATA  FOR  SINGLE  FEEDBACK  LOOP 
0/ 

1  4  2  3  0  10  0.8 

10  1  0.1 

10  10  0.1  $  FIRST  LVL  A 
8  153  10  00  0  1  $VALUECHANGER 

2  5  24  0.8  10  0.2$  B  FAIL  INPUT 
6  9  1-6-6$  TYPE  9  MODEL1 

5  1  0.8  0.2  $  SECOND  LVL  B/C 
EOR 


Table  42.  G02  Data  For  Single  Feedback  Loop. 


Table  43.  G03  Data  For  Single  Feedback  Loop. 
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G01  DATA  FOR  STANDARD  FEEDBACK  LOOP 
. 10/ 

4  1  3  1  2  3  $  FIRST  LVL  A 
12  4  1  2  4  5  $  PATH  SPLITTER 
15  8  5  6  $  VALUE  CHANGER 

4  2  2  7  8  $  SECOND  LVL  B 
9  6  6  7  9  $  TYPE  9  MODEL1 
9  94  8  12$TYPE9MODEL2 
2  0  32  6  9  10$  OR  GATE 

1  5  10  11  $  THIRD  LVLC 

5  3  13  $  DECISION  C  INPUT 

9  7  11  13  14$TYPE9MODEL3 

2  0  534  11  12  14  15$  OR  GATE 
1  5  15  16$  FOURTH  LVL  D 

0  16  $  FINAL  SIGNALS 
EOR 


Table  44.  GOl  Data  For  Standard  Feedback  Loop. 

G02  DATA  FOR  STANDARD  FEEDBACK  LOOP 
0/ 

1  4  3  3  0  10  10  0.8 
10  1  100.1 

10  10  2  0.1  $  FIRST  LVL  A 

4  12  2  0.6  0.1  $  PATH  SPLITTER 

8  153  100  0  0  1  $VALUECHANGER 

2  4  224  100.8 
10  5  0.2  $  SECOND  LVL  B 

6  9  1-6-6$  TYPE  9  MODEL1 

9  9  1-5-5$  TYPE  9  MODEL2 

5  1  0.8  0.2  $  THIRD  LVL  C/D 

3  5  2  60.8  10  0.2  $  DECISION  C  INPUT 

7  9  1-4-4$  TYPE  9  MODEL3 
EOR 


Table  45.  G02  Data  For  Standard  Feedback  Loop. 

G03  DATA  FOR  STANDARD  FEEDBACK  LOOP 

,,,1/ 

EOR 


Table  46.  G03  Data  For  Standard  Feedback  Loop. 
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G01  DATA  FOR  COMPLEX  FEEDBACK  LOOP 
. 20/ 

4  14  12  3  17$  FIRSTLVL  A 
12  4134518$B  PATH  SPLITTER 
15  8  5  6  $  VALUE  CHANGER 
423  7  8  19$  SECOND  LVLB 
9  6  6  7  9  $  TYPE  9  MODEL1 
9  94  8  12  $TYPE9MODEL2 
9  10  18  19  20  $  TYPE  9  MODEL21 
203269  10$  OR  GATE 
12  14  10  2  11  21  $BPATH  SPLITTER 

4  3  2  13  22  $  DECISION  C  INPUT 
9  7  11  13  14$TYPE9  MODEL3 

9  1 1  21  22  23  $  TYPE  9  MODEL32 
2  0534  11  12  14  15$  OR  GATE 

1  13  15  16  $  FOURTH  LVL  D 

5  5  24$  DECISION  D  INPUT 

9  12  16  24  25  $  TYPE  9  MODEL33 

2  0  7  16  17  18  20  21  23  25  26  $  OR  GATE 
1  13  26  27  $  FIFTH  LVL  E 

0  26  $  FINAL  SIGNALS 
EOR 


Table  47.  GOl  Data  For  Complex  Feedback  Loop. 


73 


G02  DATA  FOR  COMPLEX  FEEDBACK  LOOP 
0/ 

1  4  44  0  20  20  20  0.7 

20  1  20  20  0.1 
20  20  2  20  0.1 

20  20  20  7  0.1  SFIRSTLVLA 

4  12  3  0.50.1  0.1  $  PATH  SPLITTER 

8  15  3  20  0  0  0  1  $  VALUE  CHANGER 

2  4  3  34  20  20  0.8 

20  5  20  0.1 

20  20  8  0.1  $  SECOND  LVLB 

6  9  1 -16-16$TYPE9MODEL1 

9  9  1 -15-15$TYPE9  MODEL2 

10  9  1 -12-12$TYPE9MODEL22 
14  12  2  0.6  0.1  $  PATH  SPLITTER 

3  4  22  9  20  0.8 

20  10  0.2$  SECOND  LVLB 

7  9  1-11-11  $TYPE9MODEL3 
13  1  0.8  0.2  $  THIRD  LVL  C/D/E 

11  9  1-10-10  $  TYPE  9  MODEL31 

5  5  2  11  0.8  20  0.2$  DECISION  D  INPUT 

12  9  1-9-9  $TYPE9MODEL4 
EOR 


Table  48.  G02  Data  For  Complex  Feedback  Loop. 

G03  DATA  FOR  COMPLEX  FEEDBACK  LOOP 

,,,1/ 

EOR 


Table  49.  G03  Data  For  Complex  Feedback  Loop. 
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